From joakim.tjernlund@transmode.se Thu Aug 6 02:22:16 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12513A6C94 for ; Thu, 6 Aug 2009 02:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_20=-0.74, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxXRsMOccI7H for ; Thu, 6 Aug 2009 02:22:16 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 13D813A6B3A for ; Thu, 6 Aug 2009 02:22:15 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 094F6650002 for ; Thu, 6 Aug 2009 11:21:36 +0200 (CEST) X-KeepSent: 9DA011DB:F7CDBB54-C125760A:00327A9B; type=4; name=$KeepSent To: ospf@ietf.org X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Thu, 6 Aug 2009 11:22:14 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-06 11:22:16 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 09:22:17 -0000 In "16.1.1. The next hop calculation" one have: In the second case, the parent vertex is a network that directly connects the calculating router to the destination router. The list of next hops is then determined by examining the destination's router-LSA. For each link in the router-LSA that points back to the parent network, the link's Link Data field provides the IP address of a next hop router. The outgoing interface to use can then be derived from the next hop IP address (or it can be inherited from the parent network). Suppose that one cannot find any links that points back, is it a good idea to treat this case as a intervening router: If there is at least one intervening router in the current shortest path between the destination and the root, the destination simply inherits the set of next hops from the parent. That is, just inherit the next hops from its parents? Jocke From joakim.tjernlund@transmode.se Thu Aug 6 07:02:23 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96723A698E for ; Thu, 6 Aug 2009 07:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssqXefIt+wDL for ; Thu, 6 Aug 2009 07:02:23 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id DC0083A6B1F for ; Thu, 6 Aug 2009 07:02:21 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 0D400650001; Thu, 6 Aug 2009 16:01:43 +0200 (CEST) In-Reply-To: <4A7ADCE7.2010802@joelhalpern.com> References: <4A7ADCE7.2010802@joelhalpern.com> X-KeepSent: 8121E00F:44D27479-C125760A:004C6C4E; type=4; name=$KeepSent To: "Joel M. Halpern" X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Thu, 6 Aug 2009 16:02:22 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-06 16:02:23 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 14:02:23 -0000 "Joel M. Halpern" wrote on 06/08/2009 15:38:47: > > I am not sure what you are asking. A link advertised in OSPF may only > be used if it is advertised in both directions. Exactly, so you may encounter the scenario below when links are going down/up until all routers has recalculated everything. > Therefore, it appears taht the case you are describing can not occur. It can, so when it does you can either just give up or try to do the best you can until you find a back link. Jocke PS. Please keep the ospf list on the CC: line. > > Yours, > Joel > > Joakim Tjernlund wrote: > > In "16.1.1. The next hop calculation" one have: > > In the second case, the parent vertex is a network that > > directly connects the calculating router to the destination > > router. The list of next hops is then determined by > > examining the destination's router-LSA. For each link in > > the router-LSA that points back to the parent network, the > > link's Link Data field provides the IP address of a next hop > > router. The outgoing interface to use can then be derived > > from the next hop IP address (or it can be inherited from > > the parent network). > > > > Suppose that one cannot find any links that points back, is it a good > > idea to treat this case as a intervening router: > > > > If there is at least one intervening router in the current > > shortest path between the destination and the root, the > > destination simply inherits the set of next hops from the > > parent. > > That is, just inherit the next hops from its parents? > > > > Jocke > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > From prvs=462cdd866=acee@redback.com Thu Aug 6 11:20:08 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FCF93A6D28 for ; Thu, 6 Aug 2009 11:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+XbCxobwo0u for ; Thu, 6 Aug 2009 11:20:07 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 2B13E3A6B96 for ; Thu, 6 Aug 2009 11:18:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,335,1246863600"; d="scan'208";a="4275284" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 06 Aug 2009 11:18:44 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F34BEA56A58; Thu, 6 Aug 2009 11:18:43 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02479-04; Thu, 6 Aug 2009 11:18:43 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id A428A2BF384; Thu, 6 Aug 2009 11:18:39 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DDAAA7D-1C47-4D1E-B1EE-28D17EC1D3F7@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Thu, 6 Aug 2009 14:18:38 -0400 To: Joakim Tjernlund X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 18:25:03 -0000 Hello Joakim, On Aug 6, 2009, at 5:22 AM, Joakim Tjernlund wrote: > > In "16.1.1. The next hop calculation" one have: > In the second case, the parent vertex is a network that > directly connects the calculating router to the > destination > router. The list of next hops is then determined by > examining the destination's router-LSA. For each link in > the router-LSA that points back to the parent network, the > link's Link Data field provides the IP address of a > next hop > router. The outgoing interface to use can then be derived > from the next hop IP address (or it can be inherited from > the parent network). > > Suppose that one cannot find any links that points back, is it a good > idea to treat this case as a intervening router: > > If there is at least one intervening router in the current > shortest path between the destination and the root, the > destination simply inherits the set of next hops from the > parent. > That is, just inherit the next hops from its parents? No - if the Router-LSA doesn't have a link to the Network-LSA you don't use it in the SPF calculation. If fails the bi-directional check. Hope this helps, Acee > > Jocke > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From dkatz@juniper.net Thu Aug 6 11:29:59 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B028D3A6E03 for ; Thu, 6 Aug 2009 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QivhKX2OUYcb for ; Thu, 6 Aug 2009 11:29:58 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id F197B28C159 for ; Thu, 6 Aug 2009 11:28:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSnsg7Gqp8VbP8J7fDTMS5BPRBmIoQrHB@postini.com; Thu, 06 Aug 2009 11:29:04 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 6 Aug 2009 11:24:28 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 11:24:28 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 11:24:27 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 11:24:27 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n76IOQ097914; Thu, 6 Aug 2009 11:24:26 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Joakim Tjernlund In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Aug 2009 12:24:25 -0600 References: <4A7ADCE7.2010802@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Aug 2009 18:24:27.0242 (UTC) FILETIME=[21A5ACA0:01CA16C3] Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 18:29:59 -0000 If there is no back link, there is no link, and SPF moves on. If the network is partitioned, somebody should fix it. Ignoring the bidirectional test rule can lead to loops and black holes, particularly if other implementations are following the rules. --Dave On Aug 6, 2009, at 8:02 AM, Joakim Tjernlund wrote: > "Joel M. Halpern" wrote on 06/08/2009 15:38:47: >> >> I am not sure what you are asking. A link advertised in OSPF may >> only >> be used if it is advertised in both directions. > > Exactly, so you may encounter the scenario below when links are going > down/up until all routers has recalculated everything. > >> Therefore, it appears taht the case you are describing can not occur. > > It can, so when it does you can either just give up or try > to do the best you can until you find a back link. > > Jocke > PS. > Please keep the ospf list on the CC: line. > >> >> Yours, >> Joel >> >> Joakim Tjernlund wrote: >>> In "16.1.1. The next hop calculation" one have: >>> In the second case, the parent vertex is a network that >>> directly connects the calculating router to the >>> destination >>> router. The list of next hops is then determined by >>> examining the destination's router-LSA. For each link in >>> the router-LSA that points back to the parent network, >>> the >>> link's Link Data field provides the IP address of a >>> next hop >>> router. The outgoing interface to use can then be >>> derived >>> from the next hop IP address (or it can be inherited from >>> the parent network). >>> >>> Suppose that one cannot find any links that points back, is it a >>> good >>> idea to treat this case as a intervening router: >>> >>> If there is at least one intervening router in the >>> current >>> shortest path between the destination and the root, the >>> destination simply inherits the set of next hops from the >>> parent. >>> That is, just inherit the next hops from its parents? >>> >>> Jocke >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From joakim.tjernlund@transmode.se Thu Aug 6 12:16:26 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BFC3A6D0D for ; Thu, 6 Aug 2009 12:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MilzC+lVUfvE for ; Thu, 6 Aug 2009 12:16:25 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 193FE3A6C8F for ; Thu, 6 Aug 2009 12:16:24 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 01AC0650006; Thu, 6 Aug 2009 21:15:45 +0200 (CEST) In-Reply-To: <7DDAAA7D-1C47-4D1E-B1EE-28D17EC1D3F7@redback.com> References: <7DDAAA7D-1C47-4D1E-B1EE-28D17EC1D3F7@redback.com> X-KeepSent: FF34F627:D02472CF-C125760A:00691D43; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Thu, 6 Aug 2009 21:16:23 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-06 21:16:25 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:16:26 -0000 Acee Lindem wrote on 06/08/2009 20:18:38: > > Hello Joakim, Hi Acee, I am back with my questions :) > > On Aug 6, 2009, at 5:22 AM, Joakim Tjernlund wrote: > > > > > In "16.1.1. The next hop calculation" one have: > > In the second case, the parent vertex is a network that > > directly connects the calculating router to the > > destination > > router. The list of next hops is then determined by > > examining the destination's router-LSA. For each link in > > the router-LSA that points back to the parent network, the > > link's Link Data field provides the IP address of a > > next hop > > router. The outgoing interface to use can then be derived > > from the next hop IP address (or it can be inherited from > > the parent network). > > > > Suppose that one cannot find any links that points back, is it a good > > idea to treat this case as a intervening router: > > > > If there is at least one intervening router in the current > > shortest path between the destination and the root, the > > destination simply inherits the set of next hops from the > > parent. > > That is, just inherit the next hops from its parents? > > No - if the Router-LSA doesn't have a link to the Network-LSA you > don't use it in the SPF calculation. If fails the bi-directional check. The idea here is use some link until the remote end has updated its LSA to include the "back link" so the intervening router case will just act as a substitute until next LSA update. What I wonder is if this can cause more trouble than it solves, i.e what bad things can happen? Or won't it help at all? Jocke From dkatz@juniper.net Thu Aug 6 12:26:32 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CAC28C145 for ; Thu, 6 Aug 2009 12:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZICFihHm2Dt for ; Thu, 6 Aug 2009 12:26:28 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 1486528C0FD for ; Thu, 6 Aug 2009 12:26:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSnsuYFodTgxUY+EGiyNbJ5e9UT5HGq2j@postini.com; Thu, 06 Aug 2009 12:26:32 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 6 Aug 2009 12:22:49 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:22:50 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:22:49 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:22:49 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n76JMm099860; Thu, 6 Aug 2009 12:22:48 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <8B0EC6A8-6021-4EC2-90F6-6D352CF9911D@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Aug 2009 13:22:47 -0600 References: <7DDAAA7D-1C47-4D1E-B1EE-28D17EC1D3F7@redback.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Aug 2009 19:22:49.0066 (UTC) FILETIME=[48E59CA0:01CA16CB] Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:26:32 -0000 On Aug 6, 2009, at 1:16 PM, Joakim Tjernlund wrote: > > The idea here is use some link until the remote end has updated its > LSA > to include the "back link" so the intervening router case will just > act as a substitute until next LSA update. How do you know whether it's a transient condition? > > What I wonder is if this can cause more trouble than it solves, i.e > what > bad things can happen? Routing loops and black holes. > Or won't it help at all? Probably not. --Dave From joakim.tjernlund@transmode.se Thu Aug 6 12:28:09 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D4E28C151 for ; Thu, 6 Aug 2009 12:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXlynf+I+xjn for ; Thu, 6 Aug 2009 12:28:08 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 00B3C28C18D for ; Thu, 6 Aug 2009 12:28:07 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id C85D5650006; Thu, 6 Aug 2009 21:27:28 +0200 (CEST) In-Reply-To: References: <4A7ADCE7.2010802@joelhalpern.com> X-KeepSent: 461487ED:70F14424-C125760A:0069F572; type=4; name=$KeepSent To: Dave Katz X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Thu, 6 Aug 2009 21:28:07 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-06 21:28:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:28:09 -0000 Dave Katz wrote on 06/08/2009 20:24:25: Hi Dave :) > > If there is no back link, there is no link, and SPF moves on. If the > network is partitioned, somebody should fix it. Yes, this problem exist for a short while, until the remote route has updated it's LSA. > > Ignoring the bidirectional test rule can lead to loops and black > holes, particularly if other implementations are following the rules. hmm, can you be more specfic? Consider this example: R1 R2 R3 | | | ------- N1 Destination is R3 and R2 is the calculation router. R2 cannot find a backlink so it falls back to the intervening router case and uses the nexthops from the "parent", hoping that one of them will redirect IP frames to R3. Jocke > > --Dave > > On Aug 6, 2009, at 8:02 AM, Joakim Tjernlund wrote: > > > "Joel M. Halpern" wrote on 06/08/2009 15:38:47: > >> > >> I am not sure what you are asking. A link advertised in OSPF may > >> only > >> be used if it is advertised in both directions. > > > > Exactly, so you may encounter the scenario below when links are going > > down/up until all routers has recalculated everything. > > > >> Therefore, it appears taht the case you are describing can not occur. > > > > It can, so when it does you can either just give up or try > > to do the best you can until you find a back link. > > > > Jocke > > PS. > > Please keep the ospf list on the CC: line. > > > >> > >> Yours, > >> Joel > >> > >> Joakim Tjernlund wrote: > >>> In "16.1.1. The next hop calculation" one have: > >>> In the second case, the parent vertex is a network that > >>> directly connects the calculating router to the > >>> destination > >>> router. The list of next hops is then determined by > >>> examining the destination's router-LSA. For each link in > >>> the router-LSA that points back to the parent network, > >>> the > >>> link's Link Data field provides the IP address of a > >>> next hop > >>> router. The outgoing interface to use can then be > >>> derived > >>> from the next hop IP address (or it can be inherited from > >>> the parent network). > >>> > >>> Suppose that one cannot find any links that points back, is it a > >>> good > >>> idea to treat this case as a intervening router: > >>> > >>> If there is at least one intervening router in the > >>> current > >>> shortest path between the destination and the root, the > >>> destination simply inherits the set of next hops from the > >>> parent. > >>> That is, just inherit the next hops from its parents? > >>> > >>> Jocke > >>> > >>> _______________________________________________ > >>> OSPF mailing list > >>> OSPF@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ospf > >>> > >> > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > > > From joakim.tjernlund@transmode.se Thu Aug 6 12:32:19 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0485428C17D for ; Thu, 6 Aug 2009 12:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFykn5og3M-C for ; Thu, 6 Aug 2009 12:32:18 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 3083528C167 for ; Thu, 6 Aug 2009 12:32:18 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 6782F650006; Thu, 6 Aug 2009 21:31:39 +0200 (CEST) In-Reply-To: <8B0EC6A8-6021-4EC2-90F6-6D352CF9911D@juniper.net> References: <7DDAAA7D-1C47-4D1E-B1EE-28D17EC1D3F7@redback.com> <8B0EC6A8-6021-4EC2-90F6-6D352CF9911D@juniper.net> X-KeepSent: 2B2B263F:3E7ABFB5-C125760A:006AFBCB; type=4; name=$KeepSent To: Dave Katz X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Thu, 6 Aug 2009 21:32:18 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-06 21:32:20 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:32:19 -0000 Dave Katz wrote on 06/08/2009 21:22:47: > > > On Aug 6, 2009, at 1:16 PM, Joakim Tjernlund wrote: > > > > > The idea here is use some link until the remote end has updated its > > LSA > > to include the "back link" so the intervening router case will just > > act as a substitute until next LSA update. > > How do you know whether it's a transient condition? hmm, good question. Have to dwell on that. Assume for now that it will be transient. > > > > > What I wonder is if this can cause more trouble than it solves, i.e > > what > > bad things can happen? > > Routing loops and black holes. Can these affect other routes too? > > > Or won't it help at all? > > Probably not. But it might? Please see the other mail I just sent before this one. From prvs=462cdd866=acee@redback.com Thu Aug 6 12:35:02 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6882B3A686D for ; Thu, 6 Aug 2009 12:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPWN3sy8xvcF for ; Thu, 6 Aug 2009 12:35:01 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id C26D53A6CE6 for ; Thu, 6 Aug 2009 12:33:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,335,1246863600"; d="scan'208";a="4277663" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 06 Aug 2009 12:33:55 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1BB77398AC4; Thu, 6 Aug 2009 12:33:55 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31813-04; Thu, 6 Aug 2009 12:33:55 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id AA86E398AC3; Thu, 6 Aug 2009 12:33:54 -0700 (PDT) In-Reply-To: References: <7DDAAA7D-1C47-4D1E-B1EE-28D17EC1D3F7@redback.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Thu, 6 Aug 2009 15:33:53 -0400 To: Joakim Tjernlund X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:35:02 -0000 On Aug 6, 2009, at 3:16 PM, Joakim Tjernlund wrote: > > Acee Lindem wrote on 06/08/2009 20:18:38: >> >> Hello Joakim, > > Hi Acee, I am back with my questions :) > >> >> On Aug 6, 2009, at 5:22 AM, Joakim Tjernlund wrote: >> >>> >>> In "16.1.1. The next hop calculation" one have: >>> In the second case, the parent vertex is a network that >>> directly connects the calculating router to the >>> destination >>> router. The list of next hops is then determined by >>> examining the destination's router-LSA. For each >>> link in >>> the router-LSA that points back to the parent >>> network, the >>> link's Link Data field provides the IP address of a >>> next hop >>> router. The outgoing interface to use can then be >>> derived >>> from the next hop IP address (or it can be inherited >>> from >>> the parent network). >>> >>> Suppose that one cannot find any links that points back, is it a >>> good >>> idea to treat this case as a intervening router: >>> >>> If there is at least one intervening router in the >>> current >>> shortest path between the destination and the root, the >>> destination simply inherits the set of next hops from >>> the >>> parent. >>> That is, just inherit the next hops from its parents? >> >> No - if the Router-LSA doesn't have a link to the Network-LSA you >> don't use it in the SPF calculation. If fails the bi-directional >> check. > > The idea here is use some link until the remote end has updated its > LSA > to include the "back link" so the intervening router case will just > act as a substitute until next LSA update. > > What I wonder is if this can cause more trouble than it solves, i.e > what > bad things can happen? Or won't it help at all? I don't see that this achieves anything. If the router is reachable through an intra-area path, the SPF will find it. You don't want to do any second guessing - this will only create blackholes and routing loops. Thanks, Acee > > Jocke > From dkatz@juniper.net Thu Aug 6 15:07:51 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3B93A6D92 for ; Thu, 6 Aug 2009 15:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ln7xHBDUzDy for ; Thu, 6 Aug 2009 15:07:50 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 1B57228C176 for ; Thu, 6 Aug 2009 15:07:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSntUM8LFKY+nLx5Kqis0V8oipQljPfJp@postini.com; Thu, 06 Aug 2009 15:07:51 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 6 Aug 2009 15:05:01 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 15:05:01 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 15:05:00 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 15:05:00 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n76M50003544; Thu, 6 Aug 2009 15:05:00 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <0254B60A-FEAC-4BEB-8731-C6C00D378957@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Aug 2009 16:04:59 -0600 References: <4A7ADCE7.2010802@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Aug 2009 22:05:00.0769 (UTC) FILETIME=[F171A510:01CA16E1] Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 22:07:51 -0000 On Aug 6, 2009, at 1:28 PM, Joakim Tjernlund wrote: > Dave Katz wrote on 06/08/2009 20:24:25: > > Hi Dave :) > >> >> If there is no back link, there is no link, and SPF moves on. If the >> network is partitioned, somebody should fix it. > > Yes, this problem exist for a short while, until the remote > route has updated it's LSA. > >> >> Ignoring the bidirectional test rule can lead to loops and black >> holes, particularly if other implementations are following the rules. > > hmm, can you be more specfic? > > Consider this example: > > R1 R2 R3 > | | | > ------- N1 > > Destination is R3 and R2 is the calculation router. R2 cannot find a > backlink > so it falls back to the intervening router case and uses the nexthops > from the "parent", hoping that one of them will redirect IP frames to > R3. This is an uninteresting case, as there are no alternative paths. Further, there will be no "intervening router" in this case, since each of R1, 2, and 3 will be adjacent to only N1. There will be no next hops to inherit. The "intervening router" rule basically just points out that if the best path from A to C is through B, the next hop to C is simply the next hop to B. More or less. Where it can get much uglier is if there is a back path between R2 and R3; other routers playing properly will try to send the traffic through R3, but R3 will try to forward it locally. In this case it will probably result in the traffic just disappearing down a hole instead of being properly delivered on the alternative path. But if you start playing these games more generally, you can end up with traffic flying in circles. While routing is transiently nondeterministic, "hoping" is a bit less rigorous than required. ;-) And by "redirect" I assume you mean "forward", as "redirect" means something specific (and only applies to hosts.) In the general case, routing only converges on stability because everyone plays the game the same way, and the rules are designed to make it happen. If you change the rules or somebody plays them differently, it is very easy to break the algorithm. It's not at all clear to me why this would be interesting, even if it worked. In a modern, competent OSPF implementation (namely, one which ignores the rules about repeated LSA generation and is otherwise carefully tuned) you will see the other guy's LSA with the back link within a few milliseconds anyhow. In a well-engineered network there will be an alternative path anyhow, and traffic can be delivered on that path until the new one comes up fully. From joakim.tjernlund@transmode.se Thu Aug 6 16:06:17 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33163A6833 for ; Thu, 6 Aug 2009 16:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfEZAkoBQ-4d for ; Thu, 6 Aug 2009 16:06:17 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id B99F73A6987 for ; Thu, 6 Aug 2009 16:06:15 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 5AADC650009; Fri, 7 Aug 2009 01:05:36 +0200 (CEST) In-Reply-To: <0254B60A-FEAC-4BEB-8731-C6C00D378957@juniper.net> References: <4A7ADCE7.2010802@joelhalpern.com> <0254B60A-FEAC-4BEB-8731-C6C00D378957@juniper.net> X-KeepSent: 21FD5B44:C54A1552-C125760A:007DA4BE; type=4; name=$KeepSent To: Dave Katz X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Fri, 7 Aug 2009 01:06:15 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-07 01:06:17 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 23:06:17 -0000 Dave Katz wrote on 07/08/2009 00:04:59: > > > On Aug 6, 2009, at 1:28 PM, Joakim Tjernlund wrote: > > > Dave Katz wrote on 06/08/2009 20:24:25: > > > > Hi Dave :) > > > >> > >> If there is no back link, there is no link, and SPF moves on. If the > >> network is partitioned, somebody should fix it. > > > > Yes, this problem exist for a short while, until the remote > > route has updated it's LSA. > > > >> > >> Ignoring the bidirectional test rule can lead to loops and black > >> holes, particularly if other implementations are following the rules. > > > > hmm, can you be more specfic? > > > > Consider this example: > > > > R1 R2 R3 > > | | | > > ------- N1 > > > > Destination is R3 and R2 is the calculation router. R2 cannot find a > > backlink > > so it falls back to the intervening router case and uses the nexthops > > from the "parent", hoping that one of them will redirect IP frames to > > R3. > > This is an uninteresting case, as there are no alternative paths. Yes, it is very simple to make it clear what I am after. > Further, there will be no "intervening router" in this case, since > each of R1, 2, and 3 will be adjacent to only N1. Yes, I am just saying that in this particular case I want apply the same SPF rules as the intervening router uses. > There will be no > next hops to inherit. The "intervening router" rule basically just > points out that if the best path from A to C is through B, the next > hop to C is simply the next hop to B. More or less. > > Where it can get much uglier is if there is a back path between R2 and > R3; other routers playing properly will try to send the traffic > through R3, but R3 will try to forward it locally. hmm, don't you mean "through R2, but R2" ? > In this case it > will probably result in the traffic just disappearing down a hole > instead of being properly delivered on the alternative path. But if > you start playing these games more generally, you can end up with > traffic flying in circles. I am starting to think that my idea was a bad idea now :) > > While routing is transiently nondeterministic, "hoping" is a bit less > rigorous than required. ;-) And by "redirect" I assume you mean > "forward", as "redirect" means something specific (and only applies to > hosts.) Yes, I meant forwarding(sloppy me :) > > In the general case, routing only converges on stability because > everyone plays the game the same way, and the rules are designed to > make it happen. If you change the rules or somebody plays them > differently, it is very easy to break the algorithm. > > It's not at all clear to me why this would be interesting, even if it > worked. In a modern, competent OSPF implementation (namely, one which > ignores the rules about repeated LSA generation and is otherwise > carefully tuned) you will see the other guy's LSA with the back link > within a few milliseconds anyhow. In a well-engineered network there > will be an alternative path anyhow, and traffic can be delivered on > that path until the new one comes up fully. > > From dkatz@juniper.net Thu Aug 6 16:25:05 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4253A6A46 for ; Thu, 6 Aug 2009 16:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlreLgUVymLl for ; Thu, 6 Aug 2009 16:25:04 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id BF3BF3A6E6A for ; Thu, 6 Aug 2009 16:24:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSntmTX0/gu4iiIHSInIxQP++KA+9gNdv@postini.com; Thu, 06 Aug 2009 16:25:04 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 6 Aug 2009 16:23:09 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 16:23:09 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 16:23:09 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 16:23:08 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n76NN7005205; Thu, 6 Aug 2009 16:23:07 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <1AD4A4BE-B7C1-4BC9-8B71-22F035678F5E@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Aug 2009 17:23:07 -0600 References: <4A7ADCE7.2010802@joelhalpern.com> <0254B60A-FEAC-4BEB-8731-C6C00D378957@juniper.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Aug 2009 23:23:08.0075 (UTC) FILETIME=[DB4BC7B0:01CA16EC] Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 23:25:05 -0000 On Aug 6, 2009, at 5:06 PM, Joakim Tjernlund wrote: >>> >>> Consider this example: >>> >>> R1 R2 R3 >>> | | | >>> ------- N1 >>> >>> Destination is R3 and R2 is the calculation router. R2 cannot find a >>> backlink >>> so it falls back to the intervening router case and uses the >>> nexthops >>> from the "parent", hoping that one of them will redirect IP frames >>> to >>> R3. >> >> This is an uninteresting case, as there are no alternative paths. > > Yes, it is very simple to make it clear what I am after. > >> Further, there will be no "intervening router" in this case, since >> each of R1, 2, and 3 will be adjacent to only N1. > > Yes, I am just saying that in this particular case I want apply the > same SPF rules as the intervening router uses. But there is no intervening router to inherit the next hops from, so the particular point is moot. But in the broader context, yes, it would be possible to simply declare R3 to be the next hop, assuming that R2 has heard Hello packets from it on the wire, but as you gather this isn't such a good idea. >> >> Where it can get much uglier is if there is a back path between R2 >> and >> R3; other routers playing properly will try to send the traffic >> through R3, but R3 will try to forward it locally. > > hmm, don't you mean "through R2, but R2" ? Yes, my mistake. > >> In this case it >> will probably result in the traffic just disappearing down a hole >> instead of being properly delivered on the alternative path. But if >> you start playing these games more generally, you can end up with >> traffic flying in circles. > > I am starting to think that my idea was a bad idea now :) Stick with that thought. ;-) --Dave From joakim.tjernlund@transmode.se Thu Aug 6 16:35:09 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4733A6ADE for ; Thu, 6 Aug 2009 16:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG9Y6wCE1G11 for ; Thu, 6 Aug 2009 16:35:08 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 66E4A3A6D4C for ; Thu, 6 Aug 2009 16:34:41 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 9D4BC650013; Fri, 7 Aug 2009 01:34:02 +0200 (CEST) In-Reply-To: <1AD4A4BE-B7C1-4BC9-8B71-22F035678F5E@juniper.net> References: <4A7ADCE7.2010802@joelhalpern.com> <0254B60A-FEAC-4BEB-8731-C6C00D378957@juniper.net> <1AD4A4BE-B7C1-4BC9-8B71-22F035678F5E@juniper.net> X-KeepSent: 56CB1FFE:377A27CA-C125760A:0081576B; type=4; name=$KeepSent To: Dave Katz X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Fri, 7 Aug 2009 01:34:41 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-07 01:34:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] SPF calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 23:35:09 -0000 Dave Katz wrote on 07/08/2009 01:23:07: .... > >> In this case it > >> will probably result in the traffic just disappearing down a hole > >> instead of being properly delivered on the alternative path. But if > >> you start playing these games more generally, you can end up with > >> traffic flying in circles. > > > > I am starting to think that my idea was a bad idea now :) > > Stick with that thought. ;-) :) This really wasn't "my idea" to begin with but I figured I should try it out. From prvs=46369697a=acee@redback.com Fri Aug 7 15:17:50 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246B23A6D9A for ; Fri, 7 Aug 2009 15:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vh7neiO0ShI for ; Fri, 7 Aug 2009 15:17:49 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 06D953A6946 for ; Fri, 7 Aug 2009 15:17:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,343,1246863600"; d="scan'208";a="4315073" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 07 Aug 2009 15:17:52 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 899E88CC6CB for ; Fri, 7 Aug 2009 15:17:52 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30302-03 for ; Fri, 7 Aug 2009 15:17:52 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 423018CC6CA for ; Fri, 7 Aug 2009 15:17:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: <91881D67-1CA4-428E-A82A-FD68858C7EC7@redback.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: OSPF List From: Acee Lindem Date: Fri, 7 Aug 2009 18:17:50 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [OSPF] IETF 75 OSPF WG Meeting Materials X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 22:18:05 -0000 All the meeting materials are available. Thanks to Albert Tian for taking the minutes. Here is a URL for your convenience: https://datatracker.ietf.org/meeting/75/materials.html From joakim.tjernlund@transmode.se Mon Aug 10 11:59:51 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E043A68F5 for ; Mon, 10 Aug 2009 11:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTtdrYEf9-Qx for ; Mon, 10 Aug 2009 11:59:50 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id A78033A6A03 for ; Mon, 10 Aug 2009 11:59:49 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 66F24650003 for ; Mon, 10 Aug 2009 20:59:08 +0200 (CEST) X-KeepSent: 58ACC706:D1D7C980-C125760E:00673BB8; type=4; name=$KeepSent To: ospf@ietf.org X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Mon, 10 Aug 2009 20:59:49 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-10 20:59:51 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [OSPF] Assign router address when only unnumbered I/Fs? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:59:51 -0000 I got routers which only have unnumbered PtoP interfaces and I wonder how to advertise a host route as described in RFC 2328: [2]It is possible for all of a router's interfaces to be unnumbered point-to-point links. In this case, an IP address must be assigned to the router. This address will then be advertised in the router's router-LSA as a host route. The first that comes to mind is to just assign an IP address/32 to the loopback or dummy interface and start OSPF on that I/F. However, you can only assign one area to that I/F. How have other people solved this? Ideally there would be a command that lets me assign a IP address which will be advertised in all areas. Jocke From dkatz@juniper.net Mon Aug 10 16:10:44 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B5D3A691D for ; Mon, 10 Aug 2009 16:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QvXt9ctWsnq for ; Mon, 10 Aug 2009 16:10:43 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 04C4A3A67EC for ; Mon, 10 Aug 2009 16:10:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSoCo9P4+n2soT4oaX+bYMK+Txh16AFJ9@postini.com; Mon, 10 Aug 2009 16:10:47 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 10 Aug 2009 16:08:57 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 16:08:58 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 16:08:57 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 16:08:56 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7AN8u038910; Mon, 10 Aug 2009 16:08:56 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <84BDA4CA-5734-4769-9224-CAE9CC6DCED9@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 17:08:55 -0600 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Aug 2009 23:08:56.0961 (UTC) FILETIME=[89A51710:01CA1A0F] Cc: ospf@ietf.org Subject: Re: [OSPF] Assign router address when only unnumbered I/Fs? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 23:10:44 -0000 A router must have at least one IP address in it somewhere, be it bound to a loopback or whatnot. There's nothing wrong with advertising it in multiple areas, though particular implementations may or may not let you do so. Putting it in only one area and advertising a summary into other areas would have the same effect at forwarding time. Lots of room for implementation choices here. --Dave On Aug 10, 2009, at 12:59 PM, Joakim Tjernlund wrote: > > I got routers which only have unnumbered PtoP interfaces and I wonder > how to advertise a host route as described in RFC 2328: > [2]It is possible for all of a router's interfaces to be unnumbered > point-to-point links. In this case, an IP address must be assigned > to the router. This address will then be advertised in the > router's > router-LSA as a host route. > > The first that comes to mind is to just assign an IP address/32 to > the loopback or dummy interface and start OSPF on that I/F. However, > you > can only assign one area to that I/F. How have other people > solved this? > Ideally there would be a command that lets me assign a > IP address which will be advertised in all areas. From joakim.tjernlund@transmode.se Mon Aug 10 17:24:40 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C493A68FC for ; Mon, 10 Aug 2009 17:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkwyAxHcb6Tm for ; Mon, 10 Aug 2009 17:24:39 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 810FD28C168 for ; Mon, 10 Aug 2009 17:24:05 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id C8993650001; Tue, 11 Aug 2009 02:23:23 +0200 (CEST) In-Reply-To: <84BDA4CA-5734-4769-9224-CAE9CC6DCED9@juniper.net> References: <84BDA4CA-5734-4769-9224-CAE9CC6DCED9@juniper.net> X-KeepSent: 07FA9DB3:F4DFE2BE-C125760F:0001E8DC; type=4; name=$KeepSent To: Dave Katz X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 11 Aug 2009 02:24:05 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-11 02:24:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] Assign router address when only unnumbered I/Fs? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 00:24:40 -0000 Hi Dave :) Dave Katz wrote on 11/08/2009 01:08:55: > > A router must have at least one IP address in it somewhere, be it > bound to a loopback or whatnot. Yes. > > There's nothing wrong with advertising it in multiple areas, though > particular implementations may or may not let you do so. Putting it > in only one area and advertising a summary into other areas would have > the same effect at forwarding time. But you may not be connected to the backbone in all cases. > > Lots of room for implementation choices here. Yes, do you know of any? I Would be really like to use some existing template. Jocke > > --Dave > > On Aug 10, 2009, at 12:59 PM, Joakim Tjernlund wrote: > > > > > I got routers which only have unnumbered PtoP interfaces and I wonder > > how to advertise a host route as described in RFC 2328: > > [2]It is possible for all of a router's interfaces to be unnumbered > > point-to-point links. In this case, an IP address must be assigned > > to the router. This address will then be advertised in the > > router's > > router-LSA as a host route. > > > > The first that comes to mind is to just assign an IP address/32 to > > the loopback or dummy interface and start OSPF on that I/F. However, > > you > > can only assign one area to that I/F. How have other people > > solved this? > > Ideally there would be a command that lets me assign a > > IP address which will be advertised in all areas. > > > From dkatz@juniper.net Mon Aug 10 19:42:12 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A953A6C83 for ; Mon, 10 Aug 2009 19:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVh0vuJXkkvP for ; Mon, 10 Aug 2009 19:42:11 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 682893A67EC for ; Mon, 10 Aug 2009 19:42:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSoDahAJjHXdbgd+i3baKTaBk0Zc2cHUQ@postini.com; Mon, 10 Aug 2009 19:42:15 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 10 Aug 2009 19:40:43 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 19:40:43 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 19:40:43 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 19:40:42 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7B2eg043535; Mon, 10 Aug 2009 19:40:42 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Joakim Tjernlund In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 20:40:41 -0600 References: <84BDA4CA-5734-4769-9224-CAE9CC6DCED9@juniper.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Aug 2009 02:40:42.0880 (UTC) FILETIME=[1EF67800:01CA1A2D] Cc: ospf@ietf.org Subject: Re: [OSPF] Assign router address when only unnumbered I/Fs? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 02:42:12 -0000 On Aug 10, 2009, at 6:24 PM, Joakim Tjernlund wrote: >> >> There's nothing wrong with advertising it in multiple areas, though >> particular implementations may or may not let you do so. Putting it >> in only one area and advertising a summary into other areas would >> have >> the same effect at forwarding time. > > But you may not be connected to the backbone in all cases. True, though it would be an odd box that was configured to be in multiple areas, none of which were the backbone. > >> >> Lots of room for implementation choices here. > > Yes, do you know of any? I Would be really like to use some existing > template. There are policy languages on multiple vendors' routers that can do all sorts of stuff. Or one could imagine having a command that says "advertise the loopback address in all areas." Or you could imagine advertising the loopback address by default in any area that didn't have a numbered interface bound to it. Etc. --Dave > > Jocke > >> >> --Dave >> >> On Aug 10, 2009, at 12:59 PM, Joakim Tjernlund wrote: >> >>> >>> I got routers which only have unnumbered PtoP interfaces and I >>> wonder >>> how to advertise a host route as described in RFC 2328: >>> [2]It is possible for all of a router's interfaces to be unnumbered >>> point-to-point links. In this case, an IP address must be >>> assigned >>> to the router. This address will then be advertised in the >>> router's >>> router-LSA as a host route. >>> >>> The first that comes to mind is to just assign an IP address/32 to >>> the loopback or dummy interface and start OSPF on that I/F. However, >>> you >>> can only assign one area to that I/F. How have other people >>> solved this? >>> Ideally there would be a command that lets me assign a >>> IP address which will be advertised in all areas. >> >> >> > > From joakim.tjernlund@transmode.se Tue Aug 11 08:40:40 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36C83A69B1 for ; Tue, 11 Aug 2009 08:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_05=-1.11, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn9rXoarW7pw for ; Tue, 11 Aug 2009 08:40:40 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id E69953A6818 for ; Tue, 11 Aug 2009 08:40:39 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 969D1650007 for ; Tue, 11 Aug 2009 17:14:25 +0200 (CEST) X-KeepSent: 45370730:CCF7D393-C125760F:00536D32; type=4; name=$KeepSent To: ospf@ietf.org X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 11 Aug 2009 17:15:07 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-11 17:15:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [OSPF] BDR selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:40:40 -0000 In chap 9.4 is says: ... Routers having Router Priority of 0 are ineligible to become Designated Router.) but nothing is said about the priority of the BDR. Can a BDR have prio 0? A bit strange if so since it may become DR and DR's does not allow prio 0 From dkatz@juniper.net Tue Aug 11 10:08:14 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8DB13A70B6 for ; Tue, 11 Aug 2009 10:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RN7JWcM3yNg for ; Tue, 11 Aug 2009 10:08:14 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 40B163A70DD for ; Tue, 11 Aug 2009 10:08:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSoGlBPFpKETi+S+oLh+8vjRIXObaabB0@postini.com; Tue, 11 Aug 2009 10:08:18 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 11 Aug 2009 09:57:18 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:57:18 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:57:18 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:57:17 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7BGvG064184; Tue, 11 Aug 2009 09:57:16 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <2F0426B3-014E-4557-BCA5-8DF16348A149@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 10:57:16 -0600 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Aug 2009 16:57:17.0063 (UTC) FILETIME=[C8487170:01CA1AA4] Cc: ospf@ietf.org Subject: Re: [OSPF] BDR selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 17:08:14 -0000 If you follow the algorithm in 9.4, it explicitly discards boxes with priority 0 from the DR/BDR calculation. --Dave On Aug 11, 2009, at 9:15 AM, Joakim Tjernlund wrote: > > In chap 9.4 is says: > ... > Routers having Router Priority of 0 > are ineligible to become Designated Router.) > but nothing is said about the priority of the > BDR. Can a BDR have prio 0? > A bit strange if so since it may become DR and DR's does > not allow prio 0 > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From david.bond@iol.unh.edu Tue Aug 11 10:17:02 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60AE23A6A09 for ; Tue, 11 Aug 2009 10:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lnNwTAUoJPb for ; Tue, 11 Aug 2009 10:17:01 -0700 (PDT) Received: from postal.iol.unh.edu (postal.iol.unh.edu [132.177.123.84]) by core3.amsl.com (Postfix) with ESMTP id 9EAFA3A67BE for ; Tue, 11 Aug 2009 10:16:58 -0700 (PDT) Received: from MokonMobile (d124047.iol.unh.edu [132.177.124.47]) by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP id n7BH217v023588; Tue, 11 Aug 2009 13:02:01 -0400 From: "David Michael Bond" To: "'Joakim Tjernlund'" , References: In-Reply-To: Date: Tue, 11 Aug 2009 13:02:01 -0400 Message-ID: <001b01ca1aa5$719ef7d0$54dce770$@bond@iol.unh.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acoamh3BuQY86bnETmqnL4Jn9zRC4QACyCgQ Content-Language: en-us X-Virus-Scanned: ClamAV 0.94/9677/Tue Aug 11 09:25:47 2009 on postal.iol.unh.edu X-Virus-Status: Clean Subject: Re: [OSPF] BDR selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 17:17:02 -0000 Hello Joakim, Appendix A.3.2 covers this: Rtr Pri This router's Router Priority. Used in (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router. Thanks, ~~~~~~~~~~~ David Bond Research and Development, Routing InterOperability Laboratory, University of New Hampshire -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Joakim Tjernlund Sent: Tuesday, August 11, 2009 11:15 AM To: ospf@ietf.org Subject: [OSPF] BDR selection In chap 9.4 is says: ... Routers having Router Priority of 0 are ineligible to become Designated Router.) but nothing is said about the priority of the BDR. Can a BDR have prio 0? A bit strange if so since it may become DR and DR's does not allow prio 0 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From joakim.tjernlund@transmode.se Tue Aug 11 12:15:39 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556063A6D40 for ; Tue, 11 Aug 2009 12:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lxzhFF8ySVQ for ; Tue, 11 Aug 2009 12:15:38 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 817C03A6C83 for ; Tue, 11 Aug 2009 12:15:38 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 63FFB650007; Tue, 11 Aug 2009 19:06:30 +0200 (CEST) In-Reply-To: <001101ca1a9a$f25171b0$d6f45510$@bond@iol.unh.edu> References: <001101ca1a9a$f25171b0$d6f45510$@bond@iol.unh.edu> X-KeepSent: 8E2DEDA5:C6A01C41-C125760F:005DFD4B; type=4; name=$KeepSent To: "David Michael Bond" X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 11 Aug 2009 19:07:12 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-11 19:07:14 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] BDR selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 19:15:39 -0000 I missed that one, thanks. Jocke "David Michael Bond" wrote on 11/08/2009 17:46:52: > > Appendix A.3.2 covers this: > > Rtr Pri > This router's Router Priority. Used in (Backup) Designated > Router election. If set to 0, the router will be ineligible to > become (Backup) Designated Router. > > Thanks > > ~~~~~~~~~~~ > David Bond > Research and Development, Routing > InterOperability Laboratory, University of New Hampshire > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Joakim Tjernlund > Sent: Tuesday, August 11, 2009 11:15 AM > To: ospf@ietf.org > Subject: [OSPF] BDR selection > > > In chap 9.4 is says: > ... > Routers having Router Priority of 0 > are ineligible to become Designated Router.) > but nothing is said about the priority of the > BDR. Can a BDR have prio 0? > A bit strange if so since it may become DR and DR's does > not allow prio 0 > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > From joakim.tjernlund@transmode.se Tue Aug 11 13:29:59 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF8D3A6B72 for ; Tue, 11 Aug 2009 13:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_05=-1.11, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zuc7jeCMNB8d for ; Tue, 11 Aug 2009 13:29:59 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 68E513A6B10 for ; Tue, 11 Aug 2009 13:29:55 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 07AAC650005 for ; Tue, 11 Aug 2009 21:12:16 +0200 (CEST) X-KeepSent: C9ECF580:EBCC2D48-C125760F:006925F9; type=4; name=$KeepSent To: ospf@ietf.org X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 11 Aug 2009 21:12:59 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-11 21:12:59 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 20:30:00 -0000 Is there something in the OSPF spec which prevents it from operate on multiple PtoP interfaces with the same local IP address? I have that working, but there are arguments that this is allowed by OSPF, i.e, ethier use unnumbered links or unique local IP addresses. Jocke From farshad@onebox.com Tue Aug 11 13:50:41 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D413A6BF2 for ; Tue, 11 Aug 2009 13:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA6W7DhfXj9X for ; Tue, 11 Aug 2009 13:50:41 -0700 (PDT) Received: from cernan.electric.net (cernan.electric.net [72.35.23.19]) by core3.amsl.com (Postfix) with ESMTP id 040A83A6BE4 for ; Tue, 11 Aug 2009 13:50:40 -0700 (PDT) Received: from 1May9y-0004OS-T7 by cernan.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1May9y-0004PN-Us for ospf@ietf.org; Tue, 11 Aug 2009 13:41:30 -0700 Received: by emcmailer; Tue, 11 Aug 2009 13:41:30 -0700 Received: from [69.25.242.13] (helo=securemail.onebox.com) by cernan.electric.net with esmtp (Exim 4.69) (envelope-from ) id 1May9y-0004OS-T7 for ospf@ietf.org; Tue, 11 Aug 2009 13:41:30 -0700 Received: from homexpc (unverified [24.7.35.5]) by securemail.onebox.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Tue, 11 Aug 2009 16:41:26 -0400 From: "Sean Andersen" To: "'Joakim Tjernlund'" , References: Date: Tue, 11 Aug 2009 13:41:27 -0700 Message-ID: <0D894CD55C7449918EEA13E9271933B1@homexpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcoaworpIwHg8ddQRH6VyB9oNap92wAASCMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: X-Outbound-IP: 69.25.242.13 X-Env-From: farshad@onebox.com X-Virus-Status: Scanned by VirusSMART (c) Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 20:50:41 -0000 You should use unique IP addresses or unnumber them to another interface that is up all the time (e.g. loopback, or Ethernet) and make sure that ospf is running on the interface (loopback or ethernet) that you are using for unnumbered (do not unnumber one ptp to another ptp) Sean -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Joakim Tjernlund Sent: Tuesday, August 11, 2009 12:13 PM To: ospf@ietf.org Subject: [OSPF] multilple numbered PtoP links with the same local IP address Is there something in the OSPF spec which prevents it from operate on multiple PtoP interfaces with the same local IP address? I have that working, but there are arguments that this is allowed by OSPF, i.e, ethier use unnumbered links or unique local IP addresses. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From joakim.tjernlund@transmode.se Tue Aug 11 14:05:51 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29AF93A6C54 for ; Tue, 11 Aug 2009 14:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRN0PeSDWCdv for ; Tue, 11 Aug 2009 14:05:50 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 6161E3A68C2 for ; Tue, 11 Aug 2009 14:05:50 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 8AB74650005; Tue, 11 Aug 2009 23:03:57 +0200 (CEST) In-Reply-To: <0D894CD55C7449918EEA13E9271933B1@homexpc> References: <0D894CD55C7449918EEA13E9271933B1@homexpc> X-KeepSent: DDE622D6:D2B7CAF0-C125760F:007343CE; type=4; name=$KeepSent To: "Sean Andersen" X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 11 Aug 2009 23:04:40 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-11 23:04:41 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 21:05:51 -0000 "Sean Andersen" wrote on 11/08/2009 22:41:27: > > You should use unique IP addresses or unnumber them to another interface > that is up all the time (e.g. loopback, or Ethernet) and make sure that ospf > is running on the interface (loopback or ethernet) that you are using for > unnumbered (do not unnumber one ptp to another ptp) Why do I have to? What you describe is common practise but is not the same as one isn't allowed to. Jocke > > Sean > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Joakim Tjernlund > Sent: Tuesday, August 11, 2009 12:13 PM > To: ospf@ietf.org > Subject: [OSPF] multilple numbered PtoP links with the same local IP address > > > Is there something in the OSPF spec which prevents it from operate > on multiple PtoP interfaces with the same local IP address? > > I have that working, but there are arguments that this is allowed by > OSPF, i.e, ethier use unnumbered links or unique local IP addresses. > > Jocke From joakim.tjernlund@transmode.se Thu Aug 13 00:50:52 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF69F3A6A32 for ; Thu, 13 Aug 2009 00:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, HELO_EQ_SE=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-nndH46sJa9 for ; Thu, 13 Aug 2009 00:50:50 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 45C613A6960 for ; Thu, 13 Aug 2009 00:50:50 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 28D36650006 for ; Thu, 13 Aug 2009 09:40:02 +0200 (CEST) In-Reply-To: References: X-KeepSent: DD89259A:2632FBD1-C1257611:0029F0C7; type=4; name=$KeepSent Cc: ospf@ietf.org X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Thu, 13 Aug 2009 09:40:45 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-13 09:40:46 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 07:50:52 -0000 > Is there something in the OSPF spec which prevents it from operate > on multiple numbered PtoP interfaces with the same local IP address? > > I have that working, but there are arguments that this is allowed by > OSPF, i.e, ethier use unnumbered links or unique local IP addresses. > > Jocke Got some comments on this but nothing conclusive, I really want to know. Acee, what do you think? From prvs=47044e22b=acee@redback.com Thu Aug 13 17:50:00 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D263A683A for ; Thu, 13 Aug 2009 17:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fMJ5eTXp1KS for ; Thu, 13 Aug 2009 17:49:59 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 892463A6972 for ; Thu, 13 Aug 2009 17:49:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,377,1246863600"; d="scan'208";a="4481727" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 13 Aug 2009 17:50:01 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 94F1158375E; Thu, 13 Aug 2009 17:50:01 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19509-07; Thu, 13 Aug 2009 17:50:01 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 24085583760; Thu, 13 Aug 2009 17:50:00 -0700 (PDT) In-Reply-To: <9FA859626025B64FBC2AF149D97C944A037BD056@CORPUSMX80A.corp.emc.com> References: <9FA859626025B64FBC2AF149D97C944A033D043C@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A037BD056@CORPUSMX80A.corp.emc.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Thu, 13 Aug 2009 20:50:00 -0400 To: OSPF List X-Mailer: Apple Mail (2.753.1) Cc: Black_David@emc.com Subject: Re: [OSPF] Gen-ART review of draft-ietf-ospf-hmac-sha-05 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 00:52:27 -0000 On Aug 13, 2009, at 8:07 PM, wrote: > The -06 version of this draft has resolved all of the > comments from the Gen-ART review of the -05 version. > > Thanks, > --David > > >> -----Original Message----- >> From: Black, David >> Sent: Monday, July 20, 2009 10:20 AM >> To: 'Gen Art'; manav@alcatel-lucent.com; >> vishwas@ipinfusion.com; mfanto@aegisdatasecurity.com; >> riw@cisco.com; tony.li@tony.li; mjbarnes@cisco.com; >> rja@extremenetworks.com >> Cc: Black, David; Acee Lindem; Abhay Roy; Ross Callon; Adrian >> Farrel; ospf@ietf.org >> Subject: Gen-ART review of draft-ietf-ospf-hmac-sha-05 >> >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> >> Please resolve these comments along with any other Last Call >> comments you may receive. >> >> Document: draft-ietf-ospf-hmac-sha-05 >> Reviewer: David L. Black >> Review Date: July 20, 2009 >> IETF LC End Date: July 20, 2009 >> >> Summary: >> >> This draft is basically ready for publication, but has nits >> that should be fixed before publication. >> >> Comments: >> >> This draft extends OSPFv2 cryptographic authentication to use >> keyed HMACs based on the NIST secure hash standard family of >> hashes (SHA-*). The draft is solidly written, and is a >> reasonably straightforward application of HMAC and the SHA-* >> hashes to OSPFv2. The draft is in good shape - all of my >> comments are minor. >> >> I wonder whether the "SHOULD" requirement for implementation >> in Section 3 ought to include HMAC-SHA-224 and HMAC-SHA-384. >> I would have stated requirements for these two hashes as "MAY" >> in order to encourage use of either HMAC-SHA-256 or HMAC-SHA-512 >> when HMAC-SHA-1 is insufficient, but this is a judgment call. >> To avoid confusion, this is a request that the authors think >> about this topic; it is *not* a comment that the requirement >> needs to be changed. If the authors believe that the current >> "SHOULD" requirements for these two hashes are the right >> approach, that is acceptable to me. >> >> In Section 3.2, it would be useful for the draft to say that an >> OSPFv2 Security Association is not set up inband via OSPFv2, in >> contrast to an IPsec Security Association created via IKE. Among >> the reasons that this should be done is that the term "OSPFv2 >> Security Association" is introduced in this draft - that term >> does not occur in RFC 2328, even though Section D.3 of RFC 2328 >> defines an abstraction for which "OSPFv2 Security Association" >> is an appropriate name. I recommend stating that this term is >> new to this draft. >> >> The mention of IP Security in the next to last paragraph of >> the Security Considerations (section 4) should cite an >> informative reference, RFC 4301 would be appropriate. >> >> idnits 2.11.12 did not find any issues. >> >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> black_david@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> From acee@lindem.com Thu Aug 13 17:54:47 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C42D3A6972 for ; Thu, 13 Aug 2009 17:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S274PwC3Kj3c for ; Thu, 13 Aug 2009 17:54:46 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by core3.amsl.com (Postfix) with ESMTP id B9A843A683A for ; Thu, 13 Aug 2009 17:54:46 -0700 (PDT) Received: from [10.0.1.2] (really [66.57.18.13]) by cdptpa-omta01.mail.rr.com with ESMTP id <20090814005432684.KTCF16701@cdptpa-omta01.mail.rr.com> for ; Fri, 14 Aug 2009 00:54:32 +0000 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B2BEC76-93EB-4745-9529-BF2FADED554A@lindem.com> Cc: ospf@ietf.org Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Thu, 13 Aug 2009 20:54:30 -0400 X-Mailer: Apple Mail (2.753.1) Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 00:54:47 -0000 On Aug 13, 2009, at 3:40 AM, Joakim Tjernlund wrote: > >> Is there something in the OSPF spec which prevents it from operate >> on multiple numbered PtoP interfaces with the same local IP address? >> >> I have that working, but there are arguments that this is allowed by >> OSPF, i.e, ethier use unnumbered links or unique local IP addresses. >> >> Jocke > > Got some comments on this but nothing conclusive, I really want > to know. Acee, what do you think? Since there is only a type 1 (router link) in the Router-LSA for each unnumbered link, it makes no difference how many use the same IP address. The only OSPF protocol restriction is that you must advertise at least one intra-area IP address (via a type 3 link) in any transit area you want to be the endpoint for a virtual link. Hope this Helps, Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee@lindem.com Thu Aug 13 19:09:50 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6B63A68B9 for ; Thu, 13 Aug 2009 19:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMRxPmI73Txx for ; Thu, 13 Aug 2009 19:09:49 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by core3.amsl.com (Postfix) with ESMTP id 590F63A67A6 for ; Thu, 13 Aug 2009 19:09:49 -0700 (PDT) Received: from [10.0.1.2] (really [66.57.18.13]) by cdptpa-omta02.mail.rr.com with ESMTP id <20090813221350121.LPTO22035@cdptpa-omta02.mail.rr.com>; Thu, 13 Aug 2009 22:13:50 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85120D62-FAB3-4D6F-8479-41E8DB0F8CD3@lindem.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Thu, 13 Aug 2009 18:13:48 -0400 To: Joakim Tjernlund X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 02:09:50 -0000 On Aug 13, 2009, at 3:40 AM, Joakim Tjernlund wrote: > >> Is there something in the OSPF spec which prevents it from operate >> on multiple numbered PtoP interfaces with the same local IP address? >> >> I have that working, but there are arguments that this is allowed by >> OSPF, i.e, ethier use unnumbered links or unique local IP addresses. >> >> Jocke > > Got some comments on this but nothing conclusive, I really want > to know. Acee, what do you think? Since there is only a type 1 (router link) in the Router-LSA for each unnumbered link, it makes no difference how many use the same IP address. The only OSPF protocol restriction is that you must advertise at least one intra-area IP address (via a type 3 link) in any transit area you want to be the endpoint for a virtual link. Hope this Helps, Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From joakim.tjernlund@transmode.se Fri Aug 14 00:15:09 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6F33A676A for ; Fri, 14 Aug 2009 00:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjqI0TzZ3s4c for ; Fri, 14 Aug 2009 00:15:09 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id BF9C428C0F8 for ; Fri, 14 Aug 2009 00:15:07 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id ABABC650005; Fri, 14 Aug 2009 09:14:12 +0200 (CEST) In-Reply-To: <85120D62-FAB3-4D6F-8479-41E8DB0F8CD3@lindem.com> References: <85120D62-FAB3-4D6F-8479-41E8DB0F8CD3@lindem.com> X-KeepSent: 08635555:ED456665-C1257612:00274A29; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Fri, 14 Aug 2009 09:14:11 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-14 09:14:13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 07:15:09 -0000 Acee Lindem wrote on 14/08/2009 00:13:48: > > > > >> Is there something in the OSPF spec which prevents it from operate > >> on multiple numbered PtoP interfaces with the same local IP address? > >> > >> I have that working, but there are arguments that this is allowed by > >> OSPF, i.e, ethier use unnumbered links or unique local IP addresses. > >> > >> Jocke > > > > Got some comments on this but nothing conclusive, I really want > > to know. Acee, what do you think? > > Since there is only a type 1 (router link) in the Router-LSA for each > unnumbered link, it makes no difference how many use the same IP > address. Right, but how about multiple NUMBERED PtoP interfaces with the same local IP address? Then there will be multiple identical type 3 too. Jocke From acee@lindem.com Fri Aug 14 07:23:15 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6193A6A3A for ; Fri, 14 Aug 2009 07:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y92zNgQRfl7S for ; Fri, 14 Aug 2009 07:23:14 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id 770623A6A22 for ; Fri, 14 Aug 2009 07:23:14 -0700 (PDT) Received: from [10.0.1.2] (really [66.57.18.13]) by cdptpa-omta02.mail.rr.com with ESMTP id <20090814142318456.IKGT8845@cdptpa-omta02.mail.rr.com>; Fri, 14 Aug 2009 14:23:18 +0000 In-Reply-To: References: <85120D62-FAB3-4D6F-8479-41E8DB0F8CD3@lindem.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D0C8029-1ACD-40DA-8427-546096D6259B@lindem.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Fri, 14 Aug 2009 10:23:15 -0400 To: Joakim Tjernlund X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:23:15 -0000 On Aug 14, 2009, at 3:14 AM, Joakim Tjernlund wrote: > Acee Lindem wrote on 14/08/2009 00:13:48: >> >>> >>>> Is there something in the OSPF spec which prevents it from operate >>>> on multiple numbered PtoP interfaces with the same local IP >>>> address? >>>> >>>> I have that working, but there are arguments that this is >>>> allowed by >>>> OSPF, i.e, ethier use unnumbered links or unique local IP >>>> addresses. >>>> >>>> Jocke >>> >>> Got some comments on this but nothing conclusive, I really want >>> to know. Acee, what do you think? >> >> Since there is only a type 1 (router link) in the Router-LSA for each >> unnumbered link, it makes no difference how many use the same IP >> address. > > Right, but how about multiple NUMBERED PtoP interfaces with the > same local IP address? I'd argue that if your configuration supports this, all but one of the interfaces is unnumbered. > Then there will be multiple identical > type 3 too. Even though it is non-standard, I don't see any problems. I believe Dave alluded to the fact that some OSPF implementations may have ABR SPF optimizations which can have problems when the same address is advertised in multiple addresses - I know fixed some problems here in one implementation. Acee > > Jocke > From pauwells@cisco.com Fri Aug 14 07:30:02 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51553A6AEA for ; Fri, 14 Aug 2009 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6wa2IULngyE for ; Fri, 14 Aug 2009 07:30:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 73B333A6A63 for ; Fri, 14 Aug 2009 07:30:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFARhUqrR7O6/2dsb2JhbAC5XIgtkR0FhBk X-IronPort-AV: E=Sophos;i="4.43,380,1246838400"; d="scan'208";a="90092128" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 14 Aug 2009 14:30:06 +0000 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/8.12.11) with ESMTP id n7EEU5WV025891; Fri, 14 Aug 2009 07:30:05 -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.13.8/8.14.3) with ESMTP id n7EEU5DT022474; Fri, 14 Aug 2009 14:30:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 07:30:05 -0700 Received: from pauwells-linux.cisco.com ([10.19.20.98]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 07:30:05 -0700 Message-ID: <4A8574EC.1020808@cisco.com> Date: Fri, 14 Aug 2009 09:30:04 -0500 From: Paul Wells User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Acee Lindem , "Abhay Roy (akr)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2009 14:30:05.0367 (UTC) FILETIME=[B76BD470:01CA1CEB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=164; t=1250260206; x=1251124206; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pauwells@cisco.com; z=From:=20Paul=20Wells=20 |Subject:=20ospfv3MIB=20codepoint |Sender:=20; bh=zZ4oHvfiIyJ0MqvP9DkvrTR6qqgLKpJmSL501WCUK/w=; b=k+GT6/xsYI6uhD+ljLa4pMWY/gBcIApm68HCioqXMSTr635EvPKtVIscXG S9dXBLZpddGLlaro/SvLJ8LAzkLAkWEpUa2fghVrCHvNaH+NaKaZu5jGJ2mo JXTfSod+lu; Authentication-Results: sj-dkim-2; header.From=pauwells@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: OSPF List Subject: [OSPF] ospfv3MIB codepoint X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:30:02 -0000 Hi Acee, Abhay, Based on past experience would you have a guess as to when we could expect IANA to assign the mib-2 codepoint for ospfv3MIB? Thanks, Paul From akr@cisco.com Fri Aug 14 07:46:54 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9A43A6B36 for ; Fri, 14 Aug 2009 07:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpS+O4M5b56i for ; Fri, 14 Aug 2009 07:46:53 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6026F3A6A70 for ; Fri, 14 Aug 2009 07:46:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,380,1246838400"; d="scan'208";a="228024163" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 14 Aug 2009 14:46:58 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7EEkwVd015374; Fri, 14 Aug 2009 07:46:58 -0700 Received: from [10.21.125.6] (sjc-vpn6-1286.cisco.com [10.21.125.6]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7EEkv1m001253; Fri, 14 Aug 2009 14:46:57 GMT Message-ID: <4A8578E1.2040507@cisco.com> Date: Fri, 14 Aug 2009 07:46:57 -0700 From: Abhay Roy User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Wells References: <4A8574EC.1020808@cisco.com> In-Reply-To: <4A8574EC.1020808@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=337; t=1250261218; x=1251125218; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=akr@cisco.com; z=From:=20Abhay=20Roy=20 |Subject:=20Re=3A=20ospfv3MIB=20codepoint |Sender:=20; bh=FzGbmRKWO0hmQhcv3nFP828EDmFC/C3ID5xmcXYvsOE=; b=cThJ/MOZWud2eBoqo2Vsb4QqzvBvoVyTLLmd0Iz5/0i8C84Gpa/4SReySN Tl0vSu1Z6Dy1mxY4v0G5zF4EKy6/Owi339HzWm8wnIl9vHu0VVaQiWqnkBZ6 gYce0Q6iv+1nJFqZL2TaSc3RCecoEmQHY3Lm8tTLybBdc7hZmsRDo=; Authentication-Results: sj-dkim-1; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: OSPF List Subject: Re: [OSPF] ospfv3MIB codepoint X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:46:54 -0000 It's already assigned (191). Please see here: http://www.iana.org/assignments/smi-numbers Regards, -Abhay On 8/14/2009 7:30 AM, Paul Wells wrote: > Hi Acee, Abhay, > > Based on past experience would you have a guess as to when we could > expect IANA to assign the mib-2 codepoint for ospfv3MIB? > > Thanks, > Paul From DJOYAL@nortel.com Fri Aug 14 07:47:26 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF463A6BD0 for ; Fri, 14 Aug 2009 07:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0FXFEP2Ylel for ; Fri, 14 Aug 2009 07:47:26 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CA5153A6B8F for ; Fri, 14 Aug 2009 07:47:25 -0700 (PDT) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7EEjN905122; Fri, 14 Aug 2009 14:45:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2009 10:47:15 -0400 Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501413B252C0@zrtphxm1.corp.nortel.com> In-Reply-To: <4A8574EC.1020808@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] ospfv3MIB codepoint Thread-Index: Acoc684v74wygGUYSC240gzKMHWlygAAgsBQ References: <4A8574EC.1020808@cisco.com> From: "Daniel Joyal" To: "Paul Wells" , "Acee Lindem" , "Abhay Roy (akr)" Cc: OSPF List Subject: Re: [OSPF] ospfv3MIB codepoint X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:47:27 -0000 Paul, IANA has assigned the following mib-2 number: 191 ospfv3MIB OSPFV3-MIB MIB document is in the RFC editor's queue. -Dan > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Paul Wells > Sent: Friday, August 14, 2009 10:30 AM > To: Acee Lindem; Abhay Roy (akr) > Cc: OSPF List > Subject: [OSPF] ospfv3MIB codepoint >=20 > Hi Acee, Abhay, >=20 > Based on past experience would you have a guess as to when we=20 > could expect IANA to assign the mib-2 codepoint for ospfv3MIB? >=20 > Thanks, > Paul > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 From joakim.tjernlund@transmode.se Fri Aug 14 08:03:24 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A9D3A6A0C for ; Fri, 14 Aug 2009 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6tukjhzb-sO for ; Fri, 14 Aug 2009 08:03:23 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 2069C3A69CB for ; Fri, 14 Aug 2009 08:03:22 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 6FE22650001; Fri, 14 Aug 2009 17:03:25 +0200 (CEST) In-Reply-To: <8D0C8029-1ACD-40DA-8427-546096D6259B@lindem.com> References: <85120D62-FAB3-4D6F-8479-41E8DB0F8CD3@lindem.com> <8D0C8029-1ACD-40DA-8427-546096D6259B@lindem.com> X-KeepSent: 9F1FE728:B44F37E4-C1257612:0051AE53; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Fri, 14 Aug 2009 17:03:23 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-14 17:03:25 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:03:24 -0000 Acee Lindem wrote on 14/08/2009 16:23:15: > > On Aug 14, 2009, at 3:14 AM, Joakim Tjernlund wrote: > > > Acee Lindem wrote on 14/08/2009 00:13:48: > >> > >>> > >>>> Is there something in the OSPF spec which prevents it from operate > >>>> on multiple numbered PtoP interfaces with the same local IP > >>>> address? > >>>> > >>>> I have that working, but there are arguments that this is > >>>> allowed by > >>>> OSPF, i.e, ethier use unnumbered links or unique local IP > >>>> addresses. > >>>> > >>>> Jocke > >>> > >>> Got some comments on this but nothing conclusive, I really want > >>> to know. Acee, what do you think? > >> > >> Since there is only a type 1 (router link) in the Router-LSA for each > >> unnumbered link, it makes no difference how many use the same IP > >> address. > > > > Right, but how about multiple NUMBERED PtoP interfaces with the > > same local IP address? > > I'd argue that if your configuration supports this, all but one of > the interfaces is unnumbered. hmm, please clarify. I do mean treating each and every PtP as a numbered PtP link. Is there something that prohibits this in the spec? Of course not all routers will be able to handle this but in that case it would be a limitation in the impl. Is it allowed to have numbered on one side of the link and unnumbered on the other side? > > > > Then there will be multiple identical > > type 3 too. > > Even though it is non-standard, I don't see any problems. I believe > Dave alluded to the fact that some OSPF implementations may have ABR > SPF optimizations which can have problems when the same address is > advertised in multiple addresses - I know fixed some problems here in > one implementation. Yeah, when one only uses the router LSAs to identify the interface you are in trouble. > > Acee > > > > > Jocke > > > > From acee@lindem.com Fri Aug 14 10:11:34 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA2C3A6D68 for ; Fri, 14 Aug 2009 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcys3C+JBf-V for ; Fri, 14 Aug 2009 10:11:33 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id 3D1EA3A6CA7 for ; Fri, 14 Aug 2009 10:11:33 -0700 (PDT) Received: from [10.0.1.2] (really [66.57.18.13]) by cdptpa-omta04.mail.rr.com with ESMTP id <20090814171137280.QHDH15914@cdptpa-omta04.mail.rr.com>; Fri, 14 Aug 2009 17:11:37 +0000 In-Reply-To: References: <85120D62-FAB3-4D6F-8479-41E8DB0F8CD3@lindem.com> <8D0C8029-1ACD-40DA-8427-546096D6259B@lindem.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48F8955D-77AF-432B-A45F-73CE84EE0D5A@lindem.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Fri, 14 Aug 2009 13:11:33 -0400 To: Joakim Tjernlund X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 17:11:34 -0000 On Aug 14, 2009, at 11:03 AM, Joakim Tjernlund wrote: > Acee Lindem wrote on 14/08/2009 16:23:15: >> >> On Aug 14, 2009, at 3:14 AM, Joakim Tjernlund wrote: >> >>> Acee Lindem wrote on 14/08/2009 00:13:48: >>>> >>>>> >>>>>> Is there something in the OSPF spec which prevents it from >>>>>> operate >>>>>> on multiple numbered PtoP interfaces with the same local IP >>>>>> address? >>>>>> >>>>>> I have that working, but there are arguments that this is >>>>>> allowed by >>>>>> OSPF, i.e, ethier use unnumbered links or unique local IP >>>>>> addresses. >>>>>> >>>>>> Jocke >>>>> >>>>> Got some comments on this but nothing conclusive, I really want >>>>> to know. Acee, what do you think? >>>> >>>> Since there is only a type 1 (router link) in the Router-LSA for >>>> each >>>> unnumbered link, it makes no difference how many use the same IP >>>> address. >>> >>> Right, but how about multiple NUMBERED PtoP interfaces with the >>> same local IP address? >> >> I'd argue that if your configuration supports this, all but one of >> the interfaces is unnumbered. > > hmm, please clarify. I do mean treating each and every PtP > as a numbered PtP link. Is there something that prohibits > this in the spec? Of course not all routers will > be able to handle this but in that case it would be a > limitation in the impl. > > Is it allowed to have numbered on one side of the link > and unnumbered on the other side? Yes - this is fine. Thanks, Acee > >> >> >>> Then there will be multiple identical >>> type 3 too. >> >> Even though it is non-standard, I don't see any problems. I believe >> Dave alluded to the fact that some OSPF implementations may have ABR >> SPF optimizations which can have problems when the same address is >> advertised in multiple addresses - I know fixed some problems here in >> one implementation. > > Yeah, when one only uses the router LSAs to identify the interface > you are in trouble. > >> >> Acee >> >>> >>> Jocke >>> >> >> > From rfc-editor@rfc-editor.org Fri Aug 14 16:13:37 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4BD3A6880; Fri, 14 Aug 2009 16:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.683 X-Spam-Level: X-Spam-Status: No, score=-16.683 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gckhRahSMBa7; Fri, 14 Aug 2009 16:13:36 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id D7E393A6BB0; Fri, 14 Aug 2009 16:13:36 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id F38F6305CE8; Fri, 14 Aug 2009 16:13:03 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090814231303.F38F6305CE8@bosco.isi.edu> Date: Fri, 14 Aug 2009 16:13:03 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5613 on OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 23:13:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5613 Title: OSPF Link-Local Signaling Author: A. Zinin, A. Roy, L. Nguyen, B. Friedman, D. Yeung Status: Standards Track Date: August 2009 Mailbox: alex.zinin@alcatel-lucent.com, akr@cisco.com, lhnguyen@cisco.com, barryf@google.com, myeung@cisco.com Pages: 12 Characters: 23092 Obsoletes: RFC4813 I-D Tag: draft-ietf-ospf-lls-08.txt URL: http://www.rfc-editor.org/rfc/rfc5613.txt OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track. This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Fri Aug 14 16:14:56 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9856C3A6B76; Fri, 14 Aug 2009 16:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.988 X-Spam-Level: X-Spam-Status: No, score=-16.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA3FNInSLAng; Fri, 14 Aug 2009 16:14:55 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 881B13A6B79; Fri, 14 Aug 2009 16:14:20 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id D3CE0305CEA; Fri, 14 Aug 2009 16:13:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090814231347.D3CE0305CEA@bosco.isi.edu> Date: Fri, 14 Aug 2009 16:13:47 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5614 on Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 23:14:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5614 Title: Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding Author: R. Ogier, P. Spagnolo Status: Experimental Date: August 2009 Mailbox: rich.ogier@earthlink.net, phillipspagnolo@gmail.com Pages: 71 Characters: 170106 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ospf-manet-mdr-05.txt URL: http://www.rfc-editor.org/rfc/rfc5614.txt This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Open Shortest Path First IGP Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From asmirnov@cisco.com Sat Aug 15 05:47:06 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B442B3A6A8A for ; Sat, 15 Aug 2009 05:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBxFUjNt4rE5 for ; Sat, 15 Aug 2009 05:47:05 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 8A05B3A695F for ; Sat, 15 Aug 2009 05:47:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7FCl8LI012811; Sat, 15 Aug 2009 14:47:08 +0200 (CEST) Received: from [10.55.140.82] (ams-asmirnov-8711.cisco.com [10.55.140.82]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7FCl7S2029687; Sat, 15 Aug 2009 14:47:07 +0200 (CEST) Message-ID: <4A86AE4C.2070701@cisco.com> Date: Sat, 15 Aug 2009 14:47:08 +0200 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Joakim Tjernlund References: <85120D62-FAB3-4D6F-8479-41E8DB0F8CD3@lindem.com> <8D0C8029-1ACD-40DA-8427-546096D6259B@lindem.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 12:47:06 -0000 >>> Right, but how about multiple NUMBERED PtoP interfaces with the >>> same local IP address? >> I'd argue that if your configuration supports this, all but one of >> the interfaces is unnumbered. > Joakim, IP address must be unique and assigned to one numbered IP interface only. This has nothing to do with OSPF, it is requirement of a basic IP addressing paradigm and covered in relevant IPv4 architecture documents (no, I don't have a reference ready). This 'limitation' is the reason why unnumbered interfaces were invented in the first place. If "multiple NUMBERED PtoP interfaces with the same local IP address" worked well then nobody would bother to have unnumbered interfaces. Note that numbered interface by definition implies the interface has mask <32 bits and that remote end has IP address from the same IP subnet. If implementation allows configuration of IP address with mask of 32 bits or no mask at all then this in fact is just implementation of IP unnumbered interface where 'master' interface which owns the IP address is not explicitly shown. Conceptually it would be IP unnumbered nonetheless and should be treated by OSPF accordingly. Anton Joakim Tjernlund wrote: > Acee Lindem wrote on 14/08/2009 16:23:15: >> On Aug 14, 2009, at 3:14 AM, Joakim Tjernlund wrote: >> >>> Acee Lindem wrote on 14/08/2009 00:13:48: >>>>>> Is there something in the OSPF spec which prevents it from operate >>>>>> on multiple numbered PtoP interfaces with the same local IP >>>>>> address? >>>>>> >>>>>> I have that working, but there are arguments that this is >>>>>> allowed by >>>>>> OSPF, i.e, ethier use unnumbered links or unique local IP >>>>>> addresses. >>>>>> >>>>>> Jocke >>>>> Got some comments on this but nothing conclusive, I really want >>>>> to know. Acee, what do you think? >>>> Since there is only a type 1 (router link) in the Router-LSA for each >>>> unnumbered link, it makes no difference how many use the same IP >>>> address. >>> Right, but how about multiple NUMBERED PtoP interfaces with the >>> same local IP address? >> I'd argue that if your configuration supports this, all but one of >> the interfaces is unnumbered. > > hmm, please clarify. I do mean treating each and every PtP > as a numbered PtP link. Is there something that prohibits > this in the spec? Of course not all routers will > be able to handle this but in that case it would be a > limitation in the impl. > > Is it allowed to have numbered on one side of the link > and unnumbered on the other side? > >> >>> Then there will be multiple identical >>> type 3 too. >> Even though it is non-standard, I don't see any problems. I believe >> Dave alluded to the fact that some OSPF implementations may have ABR >> SPF optimizations which can have problems when the same address is >> advertised in multiple addresses - I know fixed some problems here in >> one implementation. > > Yeah, when one only uses the router LSAs to identify the interface > you are in trouble. > >> Acee >> >>> Jocke >>> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From joakim.tjernlund@transmode.se Sat Aug 15 06:07:14 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D703A69E1 for ; Sat, 15 Aug 2009 06:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyMXVgqAtcKA for ; Sat, 15 Aug 2009 06:07:13 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 965CC3A69BC for ; Sat, 15 Aug 2009 06:07:13 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 1D699650001; Sat, 15 Aug 2009 15:07:10 +0200 (CEST) In-Reply-To: <4A86AE4C.2070701@cisco.com> References: <85120D62-FAB3-4D6F-8479-41E8DB0F8CD3@lindem.com> <8D0C8029-1ACD-40DA-8427-546096D6259B@lindem.com> <4A86AE4C.2070701@cisco.com> X-KeepSent: 8986A3FF:69DCD62A-C1257613:0047216E; type=4; name=$KeepSent To: Anton Smirnov X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Sat, 15 Aug 2009 15:07:08 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-08-15 15:07:10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] multilple numbered PtoP links with the same local IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 13:07:14 -0000 > > >>> Right, but how about multiple NUMBERED PtoP interfaces with the > >>> same local IP address? > >> I'd argue that if your configuration supports this, all but one of > >> the interfaces is unnumbered. > > > > Joakim, > IP address must be unique and assigned to one numbered IP interface > only. This has nothing to do with OSPF, it is requirement of a basic IP > addressing paradigm and covered in relevant IPv4 architecture documents > (no, I don't have a reference ready). > This 'limitation' is the reason why unnumbered interfaces were > invented in the first place. If "multiple NUMBERED PtoP interfaces with > the same local IP address" worked well then nobody would bother to have > unnumbered interfaces. > > Note that numbered interface by definition implies the interface has > mask <32 bits and that remote end has IP address from the same IP > subnet. If implementation allows configuration of IP address with mask > of 32 bits or no mask at all then this in fact is just implementation of > IP unnumbered interface where 'master' interface which owns the IP > address is not explicitly shown. Conceptually it would be IP unnumbered > nonetheless and should be treated by OSPF accordingly. This is the case I am thinking on(numbered with mask=32), but I am treating it as a numbered interface in some cases and unnumbered in others and it works very well. The only difference OSPF makes on these two is adding Option 1 in the router LSA for the numbered one and unnumbered sends ifindex. Perhaps this conceptually a unnumbered I/F but one do not have to advertise it as such to get a working OSPF domain. Jocke From prvs=4755b0daa=acee@redback.com Wed Aug 19 08:19:55 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C183A6A82 for ; Wed, 19 Aug 2009 08:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsGBCHMwNMPZ for ; Wed, 19 Aug 2009 08:19:54 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 7500D28C420 for ; Wed, 19 Aug 2009 08:18:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,409,1246863600"; d="scan'208";a="4604926" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 19 Aug 2009 08:18:47 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F280AB16851; Wed, 19 Aug 2009 08:18:46 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15388-04; Wed, 19 Aug 2009 08:18:46 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 701ACB1684E; Wed, 19 Aug 2009 08:18:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Wed, 19 Aug 2009 11:18:44 -0400 To: OSPF List X-Mailer: Apple Mail (2.753.1) Cc: Suresh Melam Subject: [OSPF] Authentication/Confidentiality for OSPFv2 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 15:21:44 -0000 For some time we've discussed adding IPsec support for OSPFv2 analogous to what we have for OSPFv3. The draft subject draft describes how we'd build on the OSPFv3 support to support OSPFv2: http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt What are the current thoughts as far as adding this as a WG document? Thanks, Acee P.S. The formatting issues will be fixed in the next revision. From mjbarnes@cisco.com Wed Aug 19 08:29:57 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D140D3A6918 for ; Wed, 19 Aug 2009 08:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-6emfJ1jdJC for ; Wed, 19 Aug 2009 08:29:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A69903A6CEA for ; Wed, 19 Aug 2009 08:29:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJO3i0qrR7O6/2dsb2JhbAC9G4gvkVMFhBqBUw X-IronPort-AV: E=Sophos;i="4.43,409,1246838400"; d="scan'208";a="184400341" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 19 Aug 2009 15:29:13 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7JFTE8o019925; Wed, 19 Aug 2009 08:29:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7JFTEUD015516; Wed, 19 Aug 2009 15:29:14 GMT 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.3959); Wed, 19 Aug 2009 08:29:13 -0700 Received: from [128.107.115.191] ([128.107.115.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 08:29:13 -0700 Message-ID: <4A8C1A49.2060801@cisco.com> Date: Wed, 19 Aug 2009 08:29:13 -0700 From: Michael Barnes User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Acee Lindem References: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> In-Reply-To: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2009 15:29:13.0624 (UTC) FILETIME=[CE69A180:01CA20E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=722; t=1250695754; x=1251559754; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjbarnes@cisco.com; z=From:=20Michael=20Barnes=20 |Subject:=20Re=3A=20[OSPF]=20Authentication/Confidentiality =20for=20OSPFv2 |Sender:=20; bh=0AbxOUo+NaG04yi91NGESmqBDBg3MXbYmsoy7WzTC7s=; b=lC0kOOkOC4s9m/PP1kpQUeiL+ERjymLtT9sYNYC4Km5nsMov02U63exe26 uW/yX2wz94/TeMpGJq6+hD8KfZTdgBDrxUOVYlk9ynb1x/i8dd+lfbCMtJdM bbdio7A77I; Authentication-Results: sj-dkim-2; header.From=mjbarnes@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: OSPF List , Suresh Melam Subject: Re: [OSPF] Authentication/Confidentiality for OSPFv2 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 15:29:57 -0000 Hi Acee, There is at least a little end user interest in this, I think it should be a WG document. Regards, Michael Acee Lindem wrote: > For some time we've discussed adding IPsec support for OSPFv2 analogous > to what we have for OSPFv3. The draft subject draft describes how we'd > build on the OSPFv3 support to support OSPFv2: > > http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt > > What are the current thoughts as far as adding this as a WG document? > > Thanks, > Acee > P.S. The formatting issues will be fixed in the next > revision._______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From pauwells@cisco.com Wed Aug 19 09:58:40 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60D93A6A48 for ; Wed, 19 Aug 2009 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgBAfOTHx-wR for ; Wed, 19 Aug 2009 09:58:40 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 07C013A6882 for ; Wed, 19 Aug 2009 09:58:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADPMi0qrR7PE/2dsb2JhbAC9YIgvkU4FhBqBUw X-IronPort-AV: E=Sophos;i="4.43,409,1246838400"; d="scan'208";a="90711357" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Aug 2009 16:58:45 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7JGwj14017616; Wed, 19 Aug 2009 09:58:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7JGwj6Y020642; Wed, 19 Aug 2009 16:58:45 GMT 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.3959); Wed, 19 Aug 2009 09:58:45 -0700 Received: from pauwells-linux.cisco.com ([10.19.20.98]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 09:58:44 -0700 Message-ID: <4A8C2F43.6010509@cisco.com> Date: Wed, 19 Aug 2009 11:58:43 -0500 From: Paul Wells User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Acee Lindem References: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> In-Reply-To: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2009 16:58:44.0902 (UTC) FILETIME=[4FF19C60:01CA20EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1551; t=1250701125; x=1251565125; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pauwells@cisco.com; z=From:=20Paul=20Wells=20 |Subject:=20Re=3A=20[OSPF]=20Authentication/Confidentiality =20for=20OSPFv2 |Sender:=20; bh=OJqSZjmGg+w5WnvnODQDAx7dLrGEi/GzVTtcKxVyOpk=; b=PWwavH3WlwV+7TKue7UiIB+02FDYpr3ncjZAtddXHY1BZNWGftE/HlqFoB OldS6wDCaNE1jqIXWx8mat/sgjiYdC/rQx+lWQwvgSAN+Yq1Agl+vcDqUpwQ TvC6+f1g0A; Authentication-Results: sj-dkim-4; header.From=pauwells@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: OSPF List , Suresh Melam Subject: Re: [OSPF] Authentication/Confidentiality for OSPFv2 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 16:58:40 -0000 Hi Acee, Before we make this a working group document I'd like to hear what real problem in OSPFv2 this proposal is addressing. With draft-ietf-ospf-hmac-sha we are upgrading the authentication algorithms used by OSPFv2 to the same ones commonly used with IPSec. While the optional use of AH does authenticate additional bits of the IP header, I'm not sure I see a significant benefit in that. On the other hand, we lose the replay protection we currently have in OSPFv2. The only new capability I see is the option of encrypting the protocol traffic while, presumably, leaving everything else in the clear. In my opinion if you really care about confidentiality you'll run everything, including OSPF, through an IPSec tunnel. I'd rather see the WG spend it's time improving RFC 4552 by allowing for automated rekeying (at least on P2P links) rather than simply copying the existing OSPFv3 spec to OSPFv2. Regards, Paul Acee Lindem wrote: > For some time we've discussed adding IPsec support for OSPFv2 analogous > to what we have for OSPFv3. The draft subject draft describes how we'd > build on the OSPFv3 support to support OSPFv2: > > http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt > > What are the current thoughts as far as adding this as a WG document? > > Thanks, > Acee > P.S. The formatting issues will be fixed in the next > revision._______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From rfc-editor@rfc-editor.org Thu Aug 20 16:56:06 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80A73A6D9F; Thu, 20 Aug 2009 16:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.754 X-Spam-Level: X-Spam-Status: No, score=-16.754 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAWZGD5r+ebZ; Thu, 20 Aug 2009 16:56:05 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C29C03A6B54; Thu, 20 Aug 2009 16:56:05 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 7D5DE30CE1E; Thu, 20 Aug 2009 16:55:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090820235559.7D5DE30CE1E@bosco.isi.edu> Date: Thu, 20 Aug 2009 16:55:59 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5642 on Dynamic Hostname Exchange Mechanism for OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 23:56:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5642 Title: Dynamic Hostname Exchange Mechanism for OSPF Author: S. Venkata, S. Harwani, C. Pignataro, D. McPherson Status: Standards Track Date: August 2009 Mailbox: svenkata@google.com, sharwani@cisco.com, cpignata@cisco.com, danny@arbor.net Pages: 8 Characters: 19227 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ospf-dynamic-hostname-05.txt URL: http://www.rfc-editor.org/rfc/rfc5642.txt This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3. [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From prvs=481bf907d=acee@redback.com Tue Aug 25 10:21:18 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8E828C4E9 for ; Tue, 25 Aug 2009 10:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVb273j4BseH for ; Tue, 25 Aug 2009 10:21:17 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id D217828C4CE for ; Tue, 25 Aug 2009 10:21:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,273,1249282800"; d="scan'208";a="4764229" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 25 Aug 2009 10:21:24 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 844E8A67BA; Tue, 25 Aug 2009 10:21:24 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06348-04; Tue, 25 Aug 2009 10:21:24 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id E99D3A67B9; Tue, 25 Aug 2009 10:21:23 -0700 (PDT) In-Reply-To: <4A8C2F43.6010509@cisco.com> References: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> <4A8C2F43.6010509@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19964D61-784B-4A71-BD68-9E6A1DAB3DAB@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Tue, 25 Aug 2009 13:21:22 -0400 To: Paul Wells X-Mailer: Apple Mail (2.753.1) Cc: OSPF List , Suresh Melam Subject: Re: [OSPF] Authentication/Confidentiality for OSPFv2 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 17:21:43 -0000 Hi Paul, On Aug 19, 2009, at 12:58 PM, Paul Wells wrote: > Hi Acee, > > Before we make this a working group document I'd like to hear what > real problem in OSPFv2 this proposal is addressing. > > With draft-ietf-ospf-hmac-sha we are upgrading the authentication > algorithms used by OSPFv2 to the same ones commonly used with > IPSec. While the optional use of AH does authenticate additional > bits of the IP header, I'm not sure I see a significant benefit in > that. On the other hand, we lose the replay protection we currently > have in OSPFv2. This would not replace the existing OSPFv2 authentication. Rather, it would augment it. > > The only new capability I see is the option of encrypting the > protocol traffic while, presumably, leaving everything else in the > clear. In my opinion if you really care about confidentiality > you'll run everything, including OSPF, through an IPSec tunnel. That's a valid question? What is the group feeling on this? > > I'd rather see the WG spend it's time improving RFC 4552 by > allowing for automated rekeying (at least on P2P links) rather than > simply copying the existing OSPFv3 spec to OSPFv2. Much of what is going on in this space is not within the charter of the OSPF WG. With respect to P2P links, I've thought about defining a mode of operation that would relegate OSPF(v3) topologies to P2P and P2MP allowing the use of IKEv2 for automated rekeying. In fact, it was one of those ideas I meant to propose at an OSPF WG meeting but never got around to it. Thanks, Acee > > Regards, > Paul > > Acee Lindem wrote: >> For some time we've discussed adding IPsec support for OSPFv2 >> analogous to what we have for OSPFv3. The draft subject draft >> describes how we'd build on the OSPFv3 support to support OSPFv2: >> http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt >> What are the current thoughts as far as adding this as a WG document? >> Thanks, >> Acee >> P.S. The formatting issues will be fixed in the next >> revision._______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf From vishwas.ietf@gmail.com Tue Aug 25 10:37:18 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057C83A684F for ; Tue, 25 Aug 2009 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvWWkVhUk5eg for ; Tue, 25 Aug 2009 10:37:17 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id EB3FA3A6F56 for ; Tue, 25 Aug 2009 10:37:16 -0700 (PDT) Received: by gxk17 with SMTP id 17so4626587gxk.19 for ; Tue, 25 Aug 2009 10:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IaIzFrRavBDJd+rz/AH4MaHf245VTy5qE9pWJ4L5Heo=; b=Zgye1Ych6Aazf6yWsGGKVm1Tel8hhnr/eToCnLnsgYNBZPOWeb6Luwp8u36QiEJf3H 6eP07m4SertB8no6SrI7vvVreNAzoC8c77VZKOeR2oIkPufsktaESEAPzvWoN4LsIOPl 0l0sRUorJWRCt0yTZeWH0zYIGqZyn7fkz1Ze8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T+3Xae7+kMKU5Dk4INF5qgePE+QW+aKH5tb6UeiceXjuopMjdtrKBDzsiBo14LCXZ5 vc+m36CTEGpvrbM5pG2Nj1wostxEi33j6zEfEYLTN5qRwRiams3H80hYDe3Uba2fADVP TWMVEg/GmJLWm8ivL9l44g6ZqF1LVwAsDLfNQ= MIME-Version: 1.0 Received: by 10.150.7.5 with SMTP id 5mr11089103ybg.156.1251221835779; Tue, 25 Aug 2009 10:37:15 -0700 (PDT) In-Reply-To: <19964D61-784B-4A71-BD68-9E6A1DAB3DAB@redback.com> References: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> <4A8C2F43.6010509@cisco.com> <19964D61-784B-4A71-BD68-9E6A1DAB3DAB@redback.com> Date: Tue, 25 Aug 2009 10:37:15 -0700 Message-ID: <77ead0ec0908251037y77ca5247h900ef584e7768d28@mail.gmail.com> From: Vishwas Manral To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OSPF List , Suresh Melam Subject: Re: [OSPF] Authentication/Confidentiality for OSPFv2 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 17:37:18 -0000 Hi Acee, Though I mostly agree with Paul. The advantage of having something at the IPsec level is that we do not require protocol specific extensions as long as IPsec meets the needs as we move forward. an example of this could be automatic Keying mechanism rather than manual keying. Thanks, Vishwas On Tue, Aug 25, 2009 at 10:21 AM, Acee Lindem wrote: > Hi Paul, > > On Aug 19, 2009, at 12:58 PM, Paul Wells wrote: > >> Hi Acee, >> >> Before we make this a working group document I'd like to hear what real >> problem in OSPFv2 this proposal is addressing. >> >> With draft-ietf-ospf-hmac-sha we are upgrading the authentication >> algorithms used by OSPFv2 to the same ones commonly used with IPSec. Whi= le >> the optional use of AH does authenticate additional bits of the IP heade= r, >> I'm not sure I see a significant benefit in that. On the other hand, we = lose >> the replay protection we currently have in OSPFv2. > > This would not replace the existing OSPFv2 authentication. Rather, it wou= ld > augment it. > > >> >> The only new capability I see is the option of encrypting the protocol >> traffic while, presumably, leaving everything else in the clear. In my >> opinion if you really care about confidentiality you'll run everything, >> including OSPF, through an IPSec tunnel. > > That's a valid question? What is the group feeling on this? > > >> >> I'd rather see the WG spend it's time improving RFC 4552 by allowing for >> automated rekeying (at least on P2P links) rather than simply copying th= e >> existing OSPFv3 spec to OSPFv2. > > Much of what is going on in this space is not within the charter of the O= SPF > WG. With respect to P2P links, I've thought about defining a mode of > operation that would relegate OSPF(v3) topologies to P2P and P2MP allowin= g > the use of IKEv2 for automated rekeying. In fact, it was one of those ide= as > I meant to propose at an OSPF WG meeting but never got around to it. > > Thanks, > Acee > > >> >> Regards, >> Paul >> >> Acee Lindem wrote: >>> >>> For some time we've discussed adding IPsec support for OSPFv2 analogous >>> to what we have for OSPFv3. The draft subject draft describes how we'd = build >>> on the OSPFv3 support to support OSPFv2: >>> =A0 http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt >>> What are the current thoughts as far as adding this as a WG document? >>> Thanks, >>> Acee >>> P.S. The formatting issues will be fixed in the next >>> revision._______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From sratliff@cisco.com Wed Aug 26 07:38:58 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5848D3A6C0E for ; Wed, 26 Aug 2009 07:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+wvsA3G90UZ for ; Wed, 26 Aug 2009 07:38:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 140E93A68ED for ; Wed, 26 Aug 2009 07:38:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKfllEpAZnme/2dsb2JhbADAH4g5kDQFhBqBWA X-IronPort-AV: E=Sophos;i="4.44,279,1249257600"; d="scan'208";a="55570342" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Aug 2009 14:37:28 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7QEbSiW015328; Wed, 26 Aug 2009 10:37:28 -0400 Received: from rtp-sratliff-8713.cisco.com (rtp-sratliff-8713.cisco.com [10.116.179.212]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7QEbRDp019348; Wed, 26 Aug 2009 14:37:27 GMT Message-Id: From: Stan Ratliff To: Vishwas Manral In-Reply-To: <77ead0ec0908251037y77ca5247h900ef584e7768d28@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Aug 2009 10:37:30 -0400 References: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> <4A8C2F43.6010509@cisco.com> <19964D61-784B-4A71-BD68-9E6A1DAB3DAB@redback.com> <77ead0ec0908251037y77ca5247h900ef584e7768d28@mail.gmail.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3590; t=1251297448; x=1252161448; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[OSPF]=20Authentication/Confidentiality =20for=20OSPFv2 |Sender:=20 |To:=20Vishwas=20Manral=20; bh=HeslYG5l5hs6jQ220/S7Y65bNyHvXh0hg9Sa2WG9M5E=; b=X6nfM08GLi3vMuZ5W6jFVaqS4XOiPhwgst17Cde4u33MBjLG1hNuxiCUpp LlbP6j+k7veOJn+rbArgvurAvZ3hkBAsF4Aw5lQ2lIqC5kPPZpUmZ3hYqFCC VtziPWocaG; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: OSPF List , Suresh Melam Subject: Re: [OSPF] Authentication/Confidentiality for OSPFv2 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 14:38:58 -0000 Using IPSec is great (painful, laborious, voluminous configuration aside) if you have a wired network, and static partners. It isn't so great if you're trying to deploy an ad-hoc network, and you're not really sure from moment-to-moment which of your potential partner routers you make be needing to establish an adjacency with. So, IPSec doesn't really work for me. Regards, Stan On Aug 25, 2009, at 1:37 PM, Vishwas Manral wrote: > Hi Acee, > > Though I mostly agree with Paul. The advantage of having something at > the IPsec level is that we do not require protocol specific extensions > as long as IPsec meets the needs as we move forward. an example of > this could be automatic Keying mechanism rather than manual keying. > > Thanks, > Vishwas > > On Tue, Aug 25, 2009 at 10:21 AM, Acee Lindem wrote: >> Hi Paul, >> >> On Aug 19, 2009, at 12:58 PM, Paul Wells wrote: >> >>> Hi Acee, >>> >>> Before we make this a working group document I'd like to hear what >>> real >>> problem in OSPFv2 this proposal is addressing. >>> >>> With draft-ietf-ospf-hmac-sha we are upgrading the authentication >>> algorithms used by OSPFv2 to the same ones commonly used with >>> IPSec. While >>> the optional use of AH does authenticate additional bits of the IP >>> header, >>> I'm not sure I see a significant benefit in that. On the other >>> hand, we lose >>> the replay protection we currently have in OSPFv2. >> >> This would not replace the existing OSPFv2 authentication. Rather, >> it would >> augment it. >> >> >>> >>> The only new capability I see is the option of encrypting the >>> protocol >>> traffic while, presumably, leaving everything else in the clear. >>> In my >>> opinion if you really care about confidentiality you'll run >>> everything, >>> including OSPF, through an IPSec tunnel. >> >> That's a valid question? What is the group feeling on this? >> >> >>> >>> I'd rather see the WG spend it's time improving RFC 4552 by >>> allowing for >>> automated rekeying (at least on P2P links) rather than simply >>> copying the >>> existing OSPFv3 spec to OSPFv2. >> >> Much of what is going on in this space is not within the charter of >> the OSPF >> WG. With respect to P2P links, I've thought about defining a mode of >> operation that would relegate OSPF(v3) topologies to P2P and P2MP >> allowing >> the use of IKEv2 for automated rekeying. In fact, it was one of >> those ideas >> I meant to propose at an OSPF WG meeting but never got around to it. >> >> Thanks, >> Acee >> >> >>> >>> Regards, >>> Paul >>> >>> Acee Lindem wrote: >>>> >>>> For some time we've discussed adding IPsec support for OSPFv2 >>>> analogous >>>> to what we have for OSPFv3. The draft subject draft describes how >>>> we'd build >>>> on the OSPFv3 support to support OSPFv2: >>>> http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt >>>> What are the current thoughts as far as adding this as a WG >>>> document? >>>> Thanks, >>>> Acee >>>> P.S. The formatting issues will be fixed in the next >>>> revision._______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From asmirnov@cisco.com Thu Aug 27 04:58:37 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1F13A6AB7 for ; Thu, 27 Aug 2009 04:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrehjLjmXiPp for ; Thu, 27 Aug 2009 04:58:36 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id E20C73A6D68 for ; Thu, 27 Aug 2009 04:57:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7RBs7dR001015; Thu, 27 Aug 2009 13:54:07 +0200 (CEST) Received: from [10.55.140.82] (ams-asmirnov-8711.cisco.com [10.55.140.82]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7RBs6HX012935; Thu, 27 Aug 2009 13:54:07 +0200 (CEST) Message-ID: <4A9673DF.7030805@cisco.com> Date: Thu, 27 Aug 2009 13:54:07 +0200 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Stan Ratliff References: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> <4A8C2F43.6010509@cisco.com> <19964D61-784B-4A71-BD68-9E6A1DAB3DAB@redback.com> <77ead0ec0908251037y77ca5247h900ef584e7768d28@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: OSPF List , Suresh Melam Subject: Re: [OSPF] Authentication/Confidentiality for OSPFv2 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 11:58:37 -0000 Hi Stan, I appreciate your concern that IPsec is not an option for MANET deployments but then I can't believe OSPF traffic is the only thing there which must be protected. Because if user traffic requires encryption then having OSPF encrypted by its own protocol means is not really solving any issue. In this case problem has to be addressed lower in hierarchy, probably devising encryption scheme on radio link level. So far I have never seen valid deployment scenario when routing protocol has to have protection stronger than traffic. Without understanding of target deployment scenario this looks like me-too effort. Anton Stan Ratliff wrote: > Using IPSec is great (painful, laborious, voluminous configuration > aside) if you have a wired network, and static partners. It isn't so > great if you're trying to deploy an ad-hoc network, and you're not > really sure from moment-to-moment which of your potential partner > routers you make be needing to establish an adjacency with. So, IPSec > doesn't really work for me. > > Regards, > Stan > > On Aug 25, 2009, at 1:37 PM, Vishwas Manral wrote: > >> Hi Acee, >> >> Though I mostly agree with Paul. The advantage of having something at >> the IPsec level is that we do not require protocol specific extensions >> as long as IPsec meets the needs as we move forward. an example of >> this could be automatic Keying mechanism rather than manual keying. >> >> Thanks, >> Vishwas >> >> On Tue, Aug 25, 2009 at 10:21 AM, Acee Lindem wrote: >>> Hi Paul, >>> >>> On Aug 19, 2009, at 12:58 PM, Paul Wells wrote: >>> >>>> Hi Acee, >>>> >>>> Before we make this a working group document I'd like to hear what real >>>> problem in OSPFv2 this proposal is addressing. >>>> >>>> With draft-ietf-ospf-hmac-sha we are upgrading the authentication >>>> algorithms used by OSPFv2 to the same ones commonly used with IPSec. >>>> While >>>> the optional use of AH does authenticate additional bits of the IP >>>> header, >>>> I'm not sure I see a significant benefit in that. On the other hand, >>>> we lose >>>> the replay protection we currently have in OSPFv2. >>> >>> This would not replace the existing OSPFv2 authentication. Rather, it >>> would >>> augment it. >>> >>> >>>> >>>> The only new capability I see is the option of encrypting the protocol >>>> traffic while, presumably, leaving everything else in the clear. In my >>>> opinion if you really care about confidentiality you'll run everything, >>>> including OSPF, through an IPSec tunnel. >>> >>> That's a valid question? What is the group feeling on this? >>> >>> >>>> >>>> I'd rather see the WG spend it's time improving RFC 4552 by allowing >>>> for >>>> automated rekeying (at least on P2P links) rather than simply >>>> copying the >>>> existing OSPFv3 spec to OSPFv2. >>> >>> Much of what is going on in this space is not within the charter of >>> the OSPF >>> WG. With respect to P2P links, I've thought about defining a mode of >>> operation that would relegate OSPF(v3) topologies to P2P and P2MP >>> allowing >>> the use of IKEv2 for automated rekeying. In fact, it was one of those >>> ideas >>> I meant to propose at an OSPF WG meeting but never got around to it. >>> >>> Thanks, >>> Acee >>> >>> >>>> >>>> Regards, >>>> Paul >>>> >>>> Acee Lindem wrote: >>>>> >>>>> For some time we've discussed adding IPsec support for OSPFv2 >>>>> analogous >>>>> to what we have for OSPFv3. The draft subject draft describes how >>>>> we'd build >>>>> on the OSPFv3 support to support OSPFv2: >>>>> http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt >>>>> What are the current thoughts as far as adding this as a WG document? >>>>> Thanks, >>>>> Acee >>>>> P.S. The formatting issues will be fixed in the next >>>>> revision._______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From sratliff@cisco.com Fri Aug 28 09:21:26 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0326D28C3F8 for ; Fri, 28 Aug 2009 09:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjmbeMlQC1du for ; Fri, 28 Aug 2009 09:21:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 680B23A6C66 for ; Fri, 28 Aug 2009 09:21:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,292,1249257600"; d="scan'208";a="55940846" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Aug 2009 16:21:31 +0000 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/8.12.11) with ESMTP id n7SGLUCO019703; Fri, 28 Aug 2009 12:21:30 -0400 Received: from dhcp-64-102-54-254.cisco.com (dhcp-64-102-54-254.cisco.com [64.102.54.254]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7SGLUCD026128; Fri, 28 Aug 2009 16:21:30 GMT Message-Id: <751144AB-3E87-46F6-B055-4C7BF52AF944@cisco.com> From: Stan Ratliff To: Anton Smirnov In-Reply-To: <4A9673DF.7030805@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 Aug 2009 12:21:38 -0400 References: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> <4A8C2F43.6010509@cisco.com> <19964D61-784B-4A71-BD68-9E6A1DAB3DAB@redback.com> <77ead0ec0908251037y77ca5247h900ef584e7768d28@mail.gmail.com> <4A9673DF.7030805@cisco.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5253; t=1251476491; x=1252340491; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[OSPF]=20Authentication/Confidentiality =20for=20OSPFv2 |Sender:=20 |To:=20Anton=20Smirnov=20; bh=rXcwzOcOe4PrmamTZeYMUjeexkhKsuAPAq7xUbByh+w=; b=p+zDnNs6myUs60BRtgzE9xdxP7293cmwGOe6n450HznR5nw8ReO99lQwwF CUo4nEINmqjsEW9fZQhv2Tc6N9a2+41mT6hgwWOp6dGBZ1HzyN8JmlhQD8U0 VA5HpcjJDw; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: OSPF List , Suresh Melam Subject: Re: [OSPF] Authentication/Confidentiality for OSPFv2 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:21:26 -0000 Authenticating session partners is important for mobile, ad-hoc networks. Having confidentiality and non-repudiation for control-plane traffic is extremely important as well. Deployment scenarios would be something like an ad-hoc network coming together to fight the all-too- common California wildfires. You don't want someone hacking into the network, pretending to be a routing node. The same notion applies to military networks. Regards, Stan On Aug 27, 2009, at 7:54 AM, Anton Smirnov wrote: > > Hi Stan, > I appreciate your concern that IPsec is not an option for MANET > deployments but then I can't believe OSPF traffic is the only thing > there which must be protected. Because if user traffic requires > encryption then having OSPF encrypted by its own protocol means is not > really solving any issue. In this case problem has to be addressed > lower > in hierarchy, probably devising encryption scheme on radio link level. > > So far I have never seen valid deployment scenario when routing > protocol has to have protection stronger than traffic. Without > understanding of target deployment scenario this looks like me-too > effort. > > Anton > > > > Stan Ratliff wrote: >> Using IPSec is great (painful, laborious, voluminous configuration >> aside) if you have a wired network, and static partners. It isn't so >> great if you're trying to deploy an ad-hoc network, and you're not >> really sure from moment-to-moment which of your potential partner >> routers you make be needing to establish an adjacency with. So, IPSec >> doesn't really work for me. >> >> Regards, >> Stan >> >> On Aug 25, 2009, at 1:37 PM, Vishwas Manral wrote: >> >>> Hi Acee, >>> >>> Though I mostly agree with Paul. The advantage of having something >>> at >>> the IPsec level is that we do not require protocol specific >>> extensions >>> as long as IPsec meets the needs as we move forward. an example of >>> this could be automatic Keying mechanism rather than manual keying. >>> >>> Thanks, >>> Vishwas >>> >>> On Tue, Aug 25, 2009 at 10:21 AM, Acee Lindem >>> wrote: >>>> Hi Paul, >>>> >>>> On Aug 19, 2009, at 12:58 PM, Paul Wells wrote: >>>> >>>>> Hi Acee, >>>>> >>>>> Before we make this a working group document I'd like to hear >>>>> what real >>>>> problem in OSPFv2 this proposal is addressing. >>>>> >>>>> With draft-ietf-ospf-hmac-sha we are upgrading the authentication >>>>> algorithms used by OSPFv2 to the same ones commonly used with >>>>> IPSec. >>>>> While >>>>> the optional use of AH does authenticate additional bits of the IP >>>>> header, >>>>> I'm not sure I see a significant benefit in that. On the other >>>>> hand, >>>>> we lose >>>>> the replay protection we currently have in OSPFv2. >>>> >>>> This would not replace the existing OSPFv2 authentication. >>>> Rather, it >>>> would >>>> augment it. >>>> >>>> >>>>> >>>>> The only new capability I see is the option of encrypting the >>>>> protocol >>>>> traffic while, presumably, leaving everything else in the clear. >>>>> In my >>>>> opinion if you really care about confidentiality you'll run >>>>> everything, >>>>> including OSPF, through an IPSec tunnel. >>>> >>>> That's a valid question? What is the group feeling on this? >>>> >>>> >>>>> >>>>> I'd rather see the WG spend it's time improving RFC 4552 by >>>>> allowing >>>>> for >>>>> automated rekeying (at least on P2P links) rather than simply >>>>> copying the >>>>> existing OSPFv3 spec to OSPFv2. >>>> >>>> Much of what is going on in this space is not within the charter of >>>> the OSPF >>>> WG. With respect to P2P links, I've thought about defining a mode >>>> of >>>> operation that would relegate OSPF(v3) topologies to P2P and P2MP >>>> allowing >>>> the use of IKEv2 for automated rekeying. In fact, it was one of >>>> those >>>> ideas >>>> I meant to propose at an OSPF WG meeting but never got around to >>>> it. >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>>> >>>>> Regards, >>>>> Paul >>>>> >>>>> Acee Lindem wrote: >>>>>> >>>>>> For some time we've discussed adding IPsec support for OSPFv2 >>>>>> analogous >>>>>> to what we have for OSPFv3. The draft subject draft describes how >>>>>> we'd build >>>>>> on the OSPFv3 support to support OSPFv2: >>>>>> http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt >>>>>> What are the current thoughts as far as adding this as a WG >>>>>> document? >>>>>> Thanks, >>>>>> Acee >>>>>> P.S. The formatting issues will be fixed in the next >>>>>> revision._______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf From rfc-editor@rfc-editor.org Mon Aug 31 18:05:38 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165B828C435; Mon, 31 Aug 2009 18:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.493 X-Spam-Level: X-Spam-Status: No, score=-16.493 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bopQZ1qCXso; Mon, 31 Aug 2009 18:05:37 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 3085028C490; Mon, 31 Aug 2009 18:05:36 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id C0199312E15; Mon, 31 Aug 2009 18:05:03 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090901010503.C0199312E15@bosco.isi.edu> Date: Mon, 31 Aug 2009 18:05:03 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5643 on Management Information Base for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 01:05:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5643 Title: Management Information Base for OSPFv3 Author: D. Joyal, Ed., V. Manral, Ed. Status: Standards Track Date: August 2009 Mailbox: djoyal@nortel.com, vishwas@ipinfusion.com Pages: 95 Characters: 192945 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ospf-ospfv3-mib-15.txt URL: http://www.rfc-editor.org/rfc/rfc5643.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute