From ospf-bounces@ietf.org Sun Feb 1 16:07:14 2009 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C01E28C1D4; Sun, 1 Feb 2009 16:07:14 -0800 (PST) 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 672BF28C1D4 for ; Sun, 1 Feb 2009 16:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_50=0.001, 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 iOP8HXbegBTQ for ; Sun, 1 Feb 2009 16:07:12 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 60CF03A6847 for ; Sun, 1 Feb 2009 16:07:10 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2009 01:06:46 +0100 To: ospf@ietf.org MIME-Version: 1.0 X-KeepSent: 50672EEA:FBB96B5F-C1257550:0083D328; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Mon, 2 Feb 2009 01:06:06 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-02-02 01:06:01, Serialize complete at 2009-02-02 01:06:01 X-OriginalArrivalTime: 02 Feb 2009 00:06:47.0073 (UTC) FILETIME=[2381A910:01C984CA] Subject: [OSPF] External route question 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org In RFC 2328, chap 16.4. Calculating AS external routes, it reads: If the forwarding address is non-zero, look up the forwarding address in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path; if no such path exists, do nothing with the LSA and consider the next in the list. If I read this literally I should only check that a intra-area or inter-area path exists. I think that the intention is that such a route should be used as forwarding address too, is that right? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Feb 1 18:26:44 2009 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F132E3A67BD; Sun, 1 Feb 2009 18:26:43 -0800 (PST) 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 985A03A67BD for ; Sun, 1 Feb 2009 18:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 YPVPoFFzt4VG for ; Sun, 1 Feb 2009 18:26:41 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id E59A83A6403 for ; Sun, 1 Feb 2009 18:26:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 67B0F57A254; Sun, 1 Feb 2009 18:26:23 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11770-02; Sun, 1 Feb 2009 18:26:23 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id AE81A57A253; Sun, 1 Feb 2009 18:26:22 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <5C8296C7-6727-4D3A-AB3A-E33AE3857898@redback.com> From: Acee Lindem Date: Sun, 1 Feb 2009 21:26:23 -0500 To: Joakim Tjernlund X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] External route question 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Jocke, On Feb 1, 2009, at 7:06 PM, Joakim Tjernlund wrote: > In RFC 2328, chap 16.4. Calculating AS external routes, it reads: > > If the forwarding address is non-zero, look up the > forwarding address in the routing table.[24] The matching > routing table entry must specify an intra-area or inter- > area > path; if no such path exists, do nothing with the LSA and > consider the next in the list. > > If I read this literally I should only check that a intra-area or > inter-area path exists. I think that the intention is that > such a route should be used as forwarding address too, is > that right? It means that if a forwarding address route exists, it is used for the the next check, (4), in the RC 2328 16.4 external route computation. I believe this is clear if you take the excerpted paragraph in context of section 16.4. Thanks, Acee > > 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 ospf-bounces@ietf.org Mon Feb 2 00:21:16 2009 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5141F3A6A07; Mon, 2 Feb 2009 00:21:16 -0800 (PST) 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 67C4B3A69FE for ; Mon, 2 Feb 2009 00:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=0.729, 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 yrCtAv89wD5w for ; Mon, 2 Feb 2009 00:21:14 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 6001F3A6A07 for ; Mon, 2 Feb 2009 00:21:13 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2009 09:20:49 +0100 In-Reply-To: <5C8296C7-6727-4D3A-AB3A-E33AE3857898@redback.com> References: <5C8296C7-6727-4D3A-AB3A-E33AE3857898@redback.com> To: Acee Lindem MIME-Version: 1.0 X-KeepSent: 0FC6E8B9:D737C7C0-C1257551:002D9CEC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Mon, 2 Feb 2009 09:20:07 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-02-02 09:20:02, Serialize complete at 2009-02-02 09:20:02 X-OriginalArrivalTime: 02 Feb 2009 08:20:49.0285 (UTC) FILETIME=[27A44350:01C9850F] Cc: ospf@ietf.org Subject: Re: [OSPF] External route question 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Acee Lindem wrote on 02/02/2009 03:26:23: > > Hi Jocke, > > On Feb 1, 2009, at 7:06 PM, Joakim Tjernlund wrote: > > > In RFC 2328, chap 16.4. Calculating AS external routes, it reads: > > > > If the forwarding address is non-zero, look up the > > forwarding address in the routing table.[24] The matching > > routing table entry must specify an intra-area or inter- > > area > > path; if no such path exists, do nothing with the LSA and > > consider the next in the list. > > > > If I read this literally I should only check that a intra-area or > > inter-area path exists. I think that the intention is that > > such a route should be used as forwarding address too, is > > that right? > > It means that if a forwarding address route exists, it is used for > the the next check, (4), in the RC 2328 16.4 external route > computation. I believe this is clear if you take the excerpted > paragraph in context of section 16.4. Thanks, (4) makes sense as is says ASBR/forwarding address Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 2 06:35:16 2009 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641FC28C218; Mon, 2 Feb 2009 06:35:16 -0800 (PST) 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 ABCA728C218 for ; Mon, 2 Feb 2009 06:35:15 -0800 (PST) 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 lWOhIDzlkQ5E for ; Mon, 2 Feb 2009 06:35:14 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id D5B1428C217 for ; Mon, 2 Feb 2009 06:35:11 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01N50I74E75S00GLY8@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Mon, 02 Feb 2009 06:34:45 -0700 (PDT) Date: Mon, 02 Feb 2009 06:34:45 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: JOAKIM.TJERNLUND@TRANSMODE.SE Message-id: <01N50I74E75U00GLY8@omega7.wr.usgs.gov> X-VMS-To: Joakim.Tjernlund@transmode.se X-VMS-Cc: PMURPHY,ospf@ietf.org MIME-version: 1.0 Cc: OSPF@IETF.ORG Subject: Re: [OSPF] External route question 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org > > Hi Jocke, > > On Feb 1, 2009, at 7:06 PM, Joakim Tjernlund wrote: > > > In RFC 2328, chap 16.4. Calculating AS external routes, it reads: > > > > If the forwarding address is non-zero, look up the > > forwarding address in the routing table.[24] The matching > > routing table entry must specify an intra-area or inter- > > area > > path; if no such path exists, do nothing with the LSA and > > consider the next in the list. > > > > If I read this literally I should only check that a intra-area or > > inter-area path exists. I think that the intention is that > > such a route should be used as forwarding address too, is > > that right? > > It means that if a forwarding address route exists, it is used for > the the next check, (4), in the RC 2328 16.4 external route > computation. I believe this is clear if you take the excerpted > paragraph in context of section 16.4. Acee is correct. But note there is a slight omission in this text. The forwarding address should not be through a stub area (or NSSA). RFC 3101 Section 2.5 corrects this omission: If the forwarding address is non-zero look up the forwarding address in the routing table. For a Type-5 LSA the matching routing table entry must specify an intra-area or inter-area path through a Type-5 capable area. For a Type-7 LSA the matching routing table entry must specify an intra-area path through the LSA's originating NSSA. If no such path exists then do nothing with this LSA and consider the next in the list. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Feb 3 00:08:54 2009 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C34928C0F0; Tue, 3 Feb 2009 00:08:54 -0800 (PST) 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 572A928C0F0 for ; Tue, 3 Feb 2009 00:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=0.706, 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 TYngebfdWv59 for ; Tue, 3 Feb 2009 00:08:53 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 9BDD328C0EE for ; Tue, 3 Feb 2009 00:08:51 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2009 09:08:31 +0100 In-Reply-To: <01N50I74E75U00GLY8@omega7.wr.usgs.gov> References: <01N50I74E75U00GLY8@omega7.wr.usgs.gov> To: "Pat Murphy - (650)329-4044" MIME-Version: 1.0 X-KeepSent: 7FD8FA4B:13D92CD8-C1257552:002BD7E5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 3 Feb 2009 09:07:50 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-02-03 09:07:43, Serialize complete at 2009-02-03 09:07:43 X-OriginalArrivalTime: 03 Feb 2009 08:08:31.0176 (UTC) FILETIME=[9A1B8480:01C985D6] Cc: OSPF@IETF.ORG Subject: Re: [OSPF] External route question 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org > > > > > Hi Jocke, > > > > On Feb 1, 2009, at 7:06 PM, Joakim Tjernlund wrote: > > > > > In RFC 2328, chap 16.4. Calculating AS external routes, it reads: > > > > > > If the forwarding address is non-zero, look up the > > > forwarding address in the routing table.[24] The matching > > > routing table entry must specify an intra-area or inter- > > > area > > > path; if no such path exists, do nothing with the LSA and > > > consider the next in the list. > > > > > > If I read this literally I should only check that a intra-area or > > > inter-area path exists. I think that the intention is that > > > such a route should be used as forwarding address too, is > > > that right? > > > > It means that if a forwarding address route exists, it is used for > > the the next check, (4), in the RC 2328 16.4 external route > > computation. I believe this is clear if you take the excerpted > > paragraph in context of section 16.4. > > Acee is correct. But note there is a slight omission in this text. The > forwarding address should not be through a stub area (or NSSA). RFC 3101 > Section 2.5 corrects this omission: > > If the forwarding address is non-zero look up the forwarding > address in the routing table. For a Type-5 LSA the matching > routing table entry must specify an intra-area or inter-area > path through a Type-5 capable area. For a Type-7 LSA the > matching routing table entry must specify an intra-area path > through the LSA's originating NSSA. If no such path exists > then do nothing with this LSA and consider the next in the > list. Thanks, a few questions though: For Type-5, how do I make sure that the matching route passes through a Type-5 capable area? For Type-7, I guess it is best just to use a route back to the originating router? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Feb 3 06:53:59 2009 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EC63A6C2E; Tue, 3 Feb 2009 06:53:59 -0800 (PST) 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 606953A6C2E for ; Tue, 3 Feb 2009 06:53:58 -0800 (PST) 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 onbCGyGLnHqs for ; Tue, 3 Feb 2009 06:53:57 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id 0F09E3A69E4 for ; Tue, 3 Feb 2009 06:53:56 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01N51X4Q9GQ800GT4K@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Tue, 03 Feb 2009 06:53:30 -0700 (PDT) Date: Tue, 03 Feb 2009 06:53:30 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: JOAKIM.TJERNLUND@TRANSMODE.SE Message-id: <01N51X4Q9HO200GT4K@omega7.wr.usgs.gov> X-VMS-To: Joakim.Tjernlund@transmode.se X-VMS-Cc: PMURPHY,ospf@ietf.org MIME-version: 1.0 Cc: OSPF@IETF.ORG Subject: Re: [OSPF] External route question 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Jocke, >> Acee is correct. But note there is a slight omission in this text. The >> forwarding address should not be through a stub area (or NSSA). RFC 3101 >> Section 2.5 corrects this omission: >> >> If the forwarding address is non-zero look up the forwarding >> address in the routing table. For a Type-5 LSA the matching >> routing table entry must specify an intra-area or inter-area >> path through a Type-5 capable area. For a Type-7 LSA the >> matching routing table entry must specify an intra-area path >> through the LSA's originating NSSA. If no such path exists >> then do nothing with this LSA and consider the next in the >> list. >For Type-5, how do I make sure that the matching route passes through a >Type-5 capable area? Just examine the next hop set of the forwarding address's routing table entry. A router in that set should be either in the backbone area or a standard area. I.e. it should not be in a stub area or an NSSA. >For Type-7, I guess it is best just to use a route back to the originating >router? Not necessarily. The route to the originating router is not always the best route to the forwarding address. One should always use the forwarding address's routing table entry. In this case any router in the next hop set should belong to the same NSSA as the LSA's originating router. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From rfc-editor@rfc-editor.org Mon Feb 9 16:16: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 1FEBD3A6C11; Mon, 9 Feb 2009 16:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.833 X-Spam-Level: X-Spam-Status: No, score=-16.833 tagged_above=-999 required=5 tests=[AWL=0.766, 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 k3CI8MHVul40; Mon, 9 Feb 2009 16:16:31 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 164A03A6C2E; Mon, 9 Feb 2009 16:16:31 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id E9D39214661; Mon, 9 Feb 2009 16:16:33 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090210001633.E9D39214661@bosco.isi.edu> Date: Mon, 9 Feb 2009 16:16:33 -0800 (PST) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5449 on OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks 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, 10 Feb 2009 00:16:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5449 Title: OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks Author: E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen Status: Experimental Date: February 2009 Mailbox: Emmanuel.Baccelli@inria.fr, Philippe.Jacquet@inria.fr, dang.nguyen@crc.ca, T.Clausen@computer.org Pages: 31 Characters: 67216 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ospf-manet-mpr-04.txt URL: http://www.rfc-editor.org/rfc/rfc5449.txt This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type". 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 jcucchiara@mindspring.com Tue Feb 10 21:46:35 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 5B68D3A67B3 for ; Tue, 10 Feb 2009 21:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, STOX_REPLY_TYPE=0.001] 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 KlweZyJs4KNB for ; Tue, 10 Feb 2009 21:46:34 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C04223A6968 for ; Tue, 10 Feb 2009 21:46:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gETahHPlh6hlz0Kj1Zt04OAQpKNMwdSAL3ucJGiEZo5ojZqHV0xA+1pzQ4jZ3aLW; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.114.45] (helo=JoanPC) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LX7ve-00006D-A1; Wed, 11 Feb 2009 00:46:35 -0500 Message-ID: <005d01c98c0c$1871b0d0$6401a8c0@JoanPC> From: "Joan Cucchiara" To: Date: Wed, 11 Feb 2009 00:46:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265409dafc13a9028d184370b3738e99ccae350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.114.45 Cc: Ronald Bonica , Dan Romascanu Subject: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt 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, 11 Feb 2009 05:46:35 -0000 Dan J. and Vishwas, First, I do apologize for being late with this review, thank you for your patience. A great deal of work went into this latest revision! Thanks for that! The MIB compilers' outputs are given, followed by output from IDNITS (http://tools.ietf.org/tools/idnits/) followed by comments. Most all comments are from prior review. Please note, where agreement was reached, the comments have been deleted. Thanks, Joan smicngPRO output ----------------- W: f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical to access specified for "ospfv3StubRouterSupport" W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value identical to access specified for "ospfv3IfState" smlint ----------- Line Severity Problem 3096 5 warning: `InetAddress' should be used instead of `InetAddressIPv6' IDNITS ------ idnits 2.11.01 tmp/draft-ietf-ospf-ospfv3-mib-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see http://trustee.ietf.org/license-info), which is required from December 16, 2008. Version 1.34 of xml2rfc can be used to produce documents with boilerplate according to the mentioned Trust License Policy document. -- Found old boilerplate from RFC 3978 Section 5.1 on line 16. The obsolete RFC 3978 Section 5.1 text: "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79." -- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC 4748 on line 4482. The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text: "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." -- Found old boilerplate from RFC 3979 Section 5 paragraph 1 on line 4493. The obsolete RFC 3979 Section 5 paragraph 1 text: "The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79." -- Found old boilerplate from RFC 3979 Section 5 paragraph 2 on line 4500. The obsolete RFC 3979 Section 5 paragraph 2 text: "Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr." -- Found old boilerplate from RFC 3979 Section 5 paragraph 3 on line 4506. The obsolete RFC 3979 Section 5 paragraph 3 text: "The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org." Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 1 warning (==), 5 comments (--). ------------- > > > General Comments > ----------------- > > 1) Need to have a read-only conformance. (NEW) NIT: would change the name from ospfv3Compliance to ospfv3FullCompliance. > > 5) The MIB did not extract using mstrip (MIB tool). > If possible, could this be fixed? This is a NIT, but still had trouble with mstrip tool. 6) NEW: Use of InetAddressType and InetAddress In several places in the MIB, the DESCRIPTION states something like "only IPv6 global address type expected" and then InetAddress (SIZE (16)) is given. First, I have to ask if this is truly the intention or would having {unknown(0), ipv6(2) } and (SIZE (0|16)) be more appropriate. Second, you restrict InetAddress at the object, but the InetAddressType as part of the conformance. Could you please choose one place or the other? I tend to prefer these restrictions be in the conformance section because it is slightly less painful to revise the conformance section, than to revise objects (but this is just my opinion). At any rate, would ask that you be consistent so restrict both InetAddressType and InetAddress either in the object's SYNTAX or add to the Conformance Section. > > > Comments in Order of the document > ---------------------------------- > (NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC to be consistent with the names of the other TCs. > > *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this > table may have a DEFVAL clause of zero (this is mentioned in > the DESCRIPTION clauses). > Not Done. Even though these are read-only objects, the DEFVAL helps Agent developers so would add this, unless there is a reason not to. > *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown) > > Please indicate what true(1) means in the > DESCRIPTION > Not Done. > > *) ospfv3HostTable > > Need to have a storageType object added to this table. > Sorry, I was not correct when I said that a storageType was needed. The MIB Guidelines specifies to either add a storageType object OR add a description to the Entry (as you have done in other Tables.) To quote from rfc4181: - "There either MUST be one columnar object with a SYNTAX value of StorageType [RFC2579] and a MAX-ACCESS value of read-create, or else the row object (table entry) DESCRIPTION clause MUST specify what happens to dynamically-created rows after an agent restart." In any case, the description in the StorageType object conflicts with the Table's description. Also, if the agent is able to create/delete rows then this needs to be documented...(from rfc4181): -"If the agent itself may also create and/or delete rows, then the conditions under which this can occur MUST be clearly documented in the row object DESCRIPTION clause." Please clarify. > > > > > *) ospfv3HostEntry and ospfv3HostStorageType > Same comment as above. > > *)ospfv3IfTable > NIT: REFERENCE clause "parameters parameters", please change to "parameters" *) ospfv3IfAdminStat Please rename to ospfv3IfAdminStatus *) Why is there no ospfv3IfOperStatus object? Typically, the AdminStatus if for setting and the OperStatus is used to read if the status changes. I think both would be appropriate here. Please comment. > > > *) ospfv3NbrTable and ospfv3CfgNbrTable > > What is the relationship between these 2 tables? > The indexing is different between the 2 tables and so > I'm wondering what the relationship is between them. > So to restate my question, there is an ospfv3CfgNbrEntry which is a single neighbor that has been configured and there is an ospfv3NbrEntry which contains info about a single neighbor, so does the ospfv3CfgNbrEntry also have an associated ospfv3NbrEntry? If so, can some explanation be given on how to look up a related entry in the ospfv3NbrEntry table once the ospfv3CfgNbrEntry is populated? If there is no relationship between these two tables then please state that in the DESCRIPTION clauses for the tables. *) ospfv3NbrRtrId NIT: says "32-bit integer" and should be "32-bit unsigned integer" > > > > Notifications > ------------ > > In general the accessible-for-notify objects should probably be > changed into read-only objects. Additionally, a timestamp should > be associated with some of these. There is an assumption made that > it is better to send out notifications rather than poll, but I'd > rather give the operator the choice on that. > > Please comment. *) ospfv3PacketSrc Same sort of issue as discussed in the General Comment Section above. This one especially mentions returning 0, but it is an InetAddressIPv6 which has OCTET STRING (SIZE (16)) so please clarify what is expected by the agent. > > Compliance Statements > ------------------------- > *) NIT: ospfv3Compliance should be renamed to ospfv3FullCompliance From jcucchiara@mindspring.com Wed Feb 11 05:29:45 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 865E13A68C0; Wed, 11 Feb 2009 05:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, MANGLED_ONLINE=2.3] 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 XztUVTuStnnl; Wed, 11 Feb 2009 05:29:44 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 19C743A6872; Wed, 11 Feb 2009 05:29:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YHvHBtu3KcsQix5BmzStrVoJ6TskWFfQuX+3tU9w0iGBGogiMvajtXIs23Eom4bA; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.114.45] (helo=JoanPC) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LXF9u-0008R1-Ue; Wed, 11 Feb 2009 08:29:47 -0500 Message-ID: <001b01c98c4c$ce2627e0$6401a8c0@JoanPC> From: "Joan Cucchiara" To: "Joan Cucchiara" , , "Dan Joyal" , "Vishwas Manral" References: <005d01c98c0c$1871b0d0$6401a8c0@JoanPC> Date: Wed, 11 Feb 2009 08:29:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654c79054d74443a823f864889ac1dc159731a49835436c9336350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.114.45 Cc: "MIB Doctors \(E-mail\)" , Ronald Bonica , Dan Romascanu Subject: Re: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt 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, 11 Feb 2009 13:29:45 -0000 Opps! Wanted to send to a few more folks! ----- Original Message ----- From: "Joan Cucchiara" To: Cc: "Ronald Bonica" ; "Dan Romascanu" Sent: Wednesday, February 11, 2009 12:46 AM Subject: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt > > Dan J. and Vishwas, > > First, I do apologize for being late with this review, > thank you for your patience. > > A great deal of work went into this > latest revision! Thanks for that! > > The MIB compilers' outputs are given, > followed by output from > IDNITS (http://tools.ietf.org/tools/idnits/) > followed by comments. > > Most all comments are from prior review. Please note, > where agreement was reached, the comments have been deleted. > > Thanks, > Joan > > > > smicngPRO output > ----------------- > > W: f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical to access > specified for "ospfv3StubRouterSupport" > W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value identical to access > specified for "ospfv3IfState" > > > smlint > ----------- > Line Severity Problem > 3096 5 warning: `InetAddress' should be used instead of `InetAddressIPv6' > > > IDNITS > ------ > idnits 2.11.01 > > tmp/draft-ietf-ospf-ospfv3-mib-13.txt: > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > http://trustee.ietf.org/license-info): > ---------------------------------------------------------------------------- > > ** It looks like you're using RFC 3978 boilerplate. You should update > this > to the boilerplate described in the IETF Trust License Policy document > (see http://trustee.ietf.org/license-info), which is required from > December 16, 2008. Version 1.34 of xml2rfc can be used to produce > documents with boilerplate according to the mentioned Trust License > Policy document. > > -- Found old boilerplate from RFC 3978 Section 5.1 on line 16. > > The obsolete RFC 3978 Section 5.1 text: > "By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79." > > -- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC 4748 on > line 4482. > > The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text: > "This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE." > > -- Found old boilerplate from RFC 3979 Section 5 paragraph 1 on line > 4493. > > The obsolete RFC 3979 Section 5 paragraph 1 text: > "The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed > to pertain to the implementation or use of the technology described > in this document or the extent to which any license under such > rights might or might not be available; nor does it represent that > it has made any independent effort to identify any such rights. > Information on the procedures with respect to rights in RFC > documents can be found in BCP 78 and BCP 79." > > -- Found old boilerplate from RFC 3979 Section 5 paragraph 2 on line > 4500. > > The obsolete RFC 3979 Section 5 paragraph 2 text: > "Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use > of such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository > at http://www.ietf.org/ipr." > > -- Found old boilerplate from RFC 3979 Section 5 paragraph 3 on line > 4506. > > The obsolete RFC 3979 Section 5 paragraph 3 text: > "The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org." > > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > ---------------------------------------------------------------------------- > > No issues found here. > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > ---------------------------------------------------------------------------- > > No issues found here. > > Miscellaneous warnings: > ---------------------------------------------------------------------------- > > == The copyright year in the IETF Trust Copyright Line does not match the > current year > > > Checking references for intended status: Proposed Standard > ---------------------------------------------------------------------------- > > (See RFCs 3967 and 4897 for information about using normative > references > to lower-maturity documents in RFCs) > > No issues found here. > > Summary: 1 error (**), 1 warning (==), 5 comments (--). > > > ------------- > >> >> >> General Comments >> ----------------- >> >> 1) Need to have a read-only conformance. > > (NEW) NIT: would change the name from > ospfv3Compliance to ospfv3FullCompliance. > > >> >> 5) The MIB did not extract using mstrip (MIB tool). >> If possible, could this be fixed? > > This is a NIT, but still had trouble with mstrip tool. > > > > 6) NEW: Use of InetAddressType and InetAddress > In several places in the MIB, the DESCRIPTION states something > like "only IPv6 global address type expected" and then > InetAddress (SIZE (16)) is given. > > First, I have to ask if this is truly the intention or would > having {unknown(0), ipv6(2) } and (SIZE (0|16)) be more appropriate. > > > Second, you restrict InetAddress at the object, but the InetAddressType > as part of the conformance. Could you please choose one place or the > other? > > I tend to prefer these restrictions be in the conformance > section because it is slightly less painful to revise the conformance > section, than to revise objects (but this is just my opinion). > At any rate, would ask that you be consistent so > restrict both InetAddressType and InetAddress either in the object's > SYNTAX or add to the Conformance Section. > > > > > >> >> >> Comments in Order of the document >> ---------------------------------- >> > > > (NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC > to be consistent with the names of the other TCs. > > > >> >> *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this >> table may have a DEFVAL clause of zero (this is mentioned in >> the DESCRIPTION clauses). >> > > Not Done. Even though these are read-only objects, the DEFVAL > helps Agent developers so would add this, unless there is a > reason not to. > >> *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown) >> >> Please indicate what true(1) means in the >> DESCRIPTION >> > > Not Done. > > > > >> >> *) ospfv3HostTable >> >> Need to have a storageType object added to this table. >> > > Sorry, I was not correct when I said that a storageType was > needed. The MIB Guidelines specifies to either add a storageType > object OR add a description to the Entry (as you have done in other > Tables.) To quote from rfc4181: > > - "There either MUST be one columnar object with a SYNTAX value of > StorageType [RFC2579] and a MAX-ACCESS value of read-create, or > else the row object (table entry) DESCRIPTION clause MUST specify > what happens to dynamically-created rows after an agent restart." > > > > In any case, the description in the StorageType object conflicts with the > Table's description. > > Also, if the agent is able to create/delete rows then > this needs to be documented...(from rfc4181): > > -"If the agent itself may also create and/or delete rows, then the > conditions under which this can occur MUST be clearly documented > in the row object DESCRIPTION clause." > > > Please clarify. > > >> >> >> >> >> *) ospfv3HostEntry and ospfv3HostStorageType >> > > Same comment as above. > > > >> >> *)ospfv3IfTable >> > > NIT: REFERENCE clause "parameters parameters", please > change to "parameters" > > > > > *) ospfv3IfAdminStat > Please rename to ospfv3IfAdminStatus > > > > *) Why is there no ospfv3IfOperStatus object? > Typically, the AdminStatus if for setting and > the OperStatus is used to read if the status > changes. I think both would be appropriate here. > Please comment. > > > >> >> >> *) ospfv3NbrTable and ospfv3CfgNbrTable >> >> What is the relationship between these 2 tables? >> The indexing is different between the 2 tables and so >> I'm wondering what the relationship is between them. >> > > So to restate my question, there is an ospfv3CfgNbrEntry which is > a single neighbor that has been configured and there is > an ospfv3NbrEntry which contains info about a single neighbor, so > does the ospfv3CfgNbrEntry also have an associated ospfv3NbrEntry? > > If so, can some explanation be given on how to look up a > related entry in the ospfv3NbrEntry table once the ospfv3CfgNbrEntry is > populated? > > If there is no relationship between these two tables then > please state that in the DESCRIPTION clauses for the tables. > > > > *) ospfv3NbrRtrId > > NIT: says "32-bit integer" and should be "32-bit unsigned integer" > > >> >> >> >> Notifications >> ------------ >> >> In general the accessible-for-notify objects should probably be >> changed into read-only objects. Additionally, a timestamp should >> be associated with some of these. There is an assumption made that >> it is better to send out notifications rather than poll, but I'd >> rather give the operator the choice on that. >> >> > > Please comment. > > *) ospfv3PacketSrc > > Same sort of issue as discussed in the General Comment Section > above. This one especially mentions returning 0, but it is an > InetAddressIPv6 which has OCTET STRING (SIZE (16)) > so please clarify what is expected by the agent. > > >> >> Compliance Statements >> ------------------------- >> > > *) NIT: ospfv3Compliance should be renamed to > ospfv3FullCompliance > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From DJOYAL@nortel.com Wed Feb 11 12:23: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 95CE13A6965; Wed, 11 Feb 2009 12:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, MANGLED_ONLINE=2.3, 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 LafPwrGwjIaW; Wed, 11 Feb 2009 12:23:31 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id C9E0B3A68FA; Wed, 11 Feb 2009 12:23:24 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1BKNP517765; Wed, 11 Feb 2009 20:23:25 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: Wed, 11 Feb 2009 15:22:00 -0500 Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501413B2506E@zrtphxm1.corp.nortel.com> In-Reply-To: <001b01c98c4c$ce2627e0$6401a8c0@JoanPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt Thread-Index: AcmMTNFmLY+wW6e/RG6qnlxN5oX3rAAOVrxQ References: <005d01c98c0c$1871b0d0$6401a8c0@JoanPC> <001b01c98c4c$ce2627e0$6401a8c0@JoanPC> From: "Daniel Joyal" To: "Joan Cucchiara" , , "Vishwas Manral" Cc: "MIB Doctors \(E-mail\)" , Ronald Bonica , Dan Romascanu Subject: Re: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt 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, 11 Feb 2009 20:23:32 -0000 Thanks Joan. I'll send additional questions and comments in a separate e-mail. -Dan=20 > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com]=20 > Sent: Wednesday, February 11, 2009 8:30 AM > To: Joan Cucchiara; ospf@ietf.org; Joyal, Daniel (BL60:SF23);=20 > Vishwas Manral > Cc: Ronald Bonica; Dan Romascanu; MIB Doctors (E-mail); David=20 > Ward; Acee Lindem; Abhay Roy > Subject: Re: [OSPF] MIB Dr. review of=20 > draft-ietf-ospf-ospfv3-mib-13.txt >=20 >=20 > Opps! Wanted to send to a few more folks! >=20 >=20 > ----- Original Message ----- > From: "Joan Cucchiara" > To: > Cc: "Ronald Bonica" ; "Dan Romascanu"=20 > > Sent: Wednesday, February 11, 2009 12:46 AM > Subject: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt >=20 >=20 > > > > Dan J. and Vishwas, > > > > First, I do apologize for being late with this review, > > thank you for your patience. > > > > A great deal of work went into this > > latest revision! Thanks for that! > > > > The MIB compilers' outputs are given, > > followed by output from > > IDNITS (http://tools.ietf.org/tools/idnits/) > > followed by comments. > > > > Most all comments are from prior review. Please note, > > where agreement was reached, the comments have been deleted. > > > > Thanks, > > Joan > > > > > > > > smicngPRO output > > ----------------- > > > > W: f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical to access=20 > > specified for "ospfv3StubRouterSupport" > > W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value identical to access=20 > > specified for "ospfv3IfState" > > > > > > smlint > > ----------- > > Line Severity Problem > > 3096 5 warning: `InetAddress' should be used instead of=20 > `InetAddressIPv6' > > > > > > IDNITS > > ------ > > idnits 2.11.01 > > > > tmp/draft-ietf-ospf-ospfv3-mib-13.txt: > > > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > > http://trustee.ietf.org/license-info): > > =20 > -------------------------------------------------------------- > -------------- > > > > ** It looks like you're using RFC 3978 boilerplate. You=20 > should update=20 > > this > > to the boilerplate described in the IETF Trust License=20 > Policy document > > (see http://trustee.ietf.org/license-info), which is=20 > required from > > December 16, 2008. Version 1.34 of xml2rfc can be used=20 > to produce > > documents with boilerplate according to the mentioned=20 > Trust License > > Policy document. > > > > -- Found old boilerplate from RFC 3978 Section 5.1 on line 16. > > > > The obsolete RFC 3978 Section 5.1 text: > > "By submitting this Internet-Draft, each author=20 > represents that any > > applicable patent or other IPR claims of which he or=20 > she is aware > > have been or will be disclosed, and any of which he or=20 > she becomes > > aware will be disclosed, in accordance with Section 6=20 > of BCP 79." > > > > -- Found old boilerplate from RFC 3978 Section 5.5 updated=20 > by RFC 4748 on > > line 4482. > > > > The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text: > > "This document and the information contained herein are=20 > provided on an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET=20 > SOCIETY, THE > > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=20 > LIMITED TO ANY > > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL=20 > NOT INFRINGE > > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 > MERCHANTABILITY OR FITNESS > > FOR A PARTICULAR PURPOSE." > > > > -- Found old boilerplate from RFC 3979 Section 5 paragraph=20 > 1 on line=20 > > 4493. > > > > The obsolete RFC 3979 Section 5 paragraph 1 text: > > "The IETF takes no position regarding the validity or=20 > scope of any > > Intellectual Property Rights or other rights that=20 > might be claimed > > to pertain to the implementation or use of the=20 > technology described > > in this document or the extent to which any license under such > > rights might or might not be available; nor does it=20 > represent that > > it has made any independent effort to identify any such rights. > > Information on the procedures with respect to rights in RFC > > documents can be found in BCP 78 and BCP 79." > > > > -- Found old boilerplate from RFC 3979 Section 5 paragraph=20 > 2 on line=20 > > 4500. > > > > The obsolete RFC 3979 Section 5 paragraph 2 text: > > "Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the=20 > result of an > > attempt made to obtain a general license or permission=20 > for the use > > of such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line=20 > IPR repository > > at http://www.ietf.org/ipr." > > > > -- Found old boilerplate from RFC 3979 Section 5 paragraph=20 > 3 on line=20 > > 4506. > > > > The obsolete RFC 3979 Section 5 paragraph 3 text: > > "The IETF invites any interested party to bring to its=20 > attention any > > copyrights, patents or patent applications, or other=20 > proprietary > > rights that may cover technology that may be required=20 > to implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org." > > > > > > Checking nits according to=20 > http://www.ietf.org/ietf/1id-guidelines.txt: > > =20 > -------------------------------------------------------------- > -------------- > > > > No issues found here. > > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > =20 > -------------------------------------------------------------- > -------------- > > > > No issues found here. > > > > Miscellaneous warnings: > > =20 > -------------------------------------------------------------- > -------------- > > > > =3D=3D The copyright year in the IETF Trust Copyright Line=20 > does not match the > > current year > > > > > > Checking references for intended status: Proposed Standard > > =20 > -------------------------------------------------------------- > -------------- > > > > (See RFCs 3967 and 4897 for information about using normative=20 > > references > > to lower-maturity documents in RFCs) > > > > No issues found here. > > > > Summary: 1 error (**), 1 warning (=3D=3D), 5 comments (--). > > > > > > ------------- > > > >> > >> > >> General Comments > >> ----------------- > >> > >> 1) Need to have a read-only conformance. > > > > (NEW) NIT: would change the name from > > ospfv3Compliance to ospfv3FullCompliance. > > > > > >> > >> 5) The MIB did not extract using mstrip (MIB tool). > >> If possible, could this be fixed? > > > > This is a NIT, but still had trouble with mstrip tool. > > > > > > > > 6) NEW: Use of InetAddressType and InetAddress > > In several places in the MIB, the DESCRIPTION states something > > like "only IPv6 global address type expected" and then > > InetAddress (SIZE (16)) is given. > > > > First, I have to ask if this is truly the intention or would > > having {unknown(0), ipv6(2) } and (SIZE (0|16)) be more=20 > appropriate. > > > > > > Second, you restrict InetAddress at the object, but the=20 > InetAddressType > > as part of the conformance. Could you please choose one=20 > place or the=20 > > other? > > > > I tend to prefer these restrictions be in the conformance > > section because it is slightly less painful to revise the=20 > conformance > > section, than to revise objects (but this is just my opinion). > > At any rate, would ask that you be consistent so > > restrict both InetAddressType and InetAddress either in the object's > > SYNTAX or add to the Conformance Section. > > > > > > > > > > > >> > >> > >> Comments in Order of the document > >> ---------------------------------- > >> > > > > > > (NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC > > to be consistent with the names of the other TCs. > > > > > > > >> > >> *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this > >> table may have a DEFVAL clause of zero (this is mentioned in > >> the DESCRIPTION clauses). > >> > > > > Not Done. Even though these are read-only objects, the DEFVAL > > helps Agent developers so would add this, unless there is a > > reason not to. > > > >> *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown) > >> > >> Please indicate what true(1) means in the > >> DESCRIPTION > >> > > > > Not Done. > > > > > > > > > >> > >> *) ospfv3HostTable > >> > >> Need to have a storageType object added to this table. > >> > > > > Sorry, I was not correct when I said that a storageType was > > needed. The MIB Guidelines specifies to either add a storageType > > object OR add a description to the Entry (as you have done in other > > Tables.) To quote from rfc4181: > > > > - "There either MUST be one columnar object with a=20 > SYNTAX value of > > StorageType [RFC2579] and a MAX-ACCESS value of=20 > read-create, or > > else the row object (table entry) DESCRIPTION clause=20 > MUST specify > > what happens to dynamically-created rows after an=20 > agent restart." > > > > > > > > In any case, the description in the StorageType object=20 > conflicts with the > > Table's description. > > > > Also, if the agent is able to create/delete rows then > > this needs to be documented...(from rfc4181): > > > > -"If the agent itself may also create and/or delete=20 > rows, then the > > conditions under which this can occur MUST be clearly=20 > documented > > in the row object DESCRIPTION clause." > > > > > > Please clarify. > > > > > >> > >> > >> > >> > >> *) ospfv3HostEntry and ospfv3HostStorageType > >> > > > > Same comment as above. > > > > > > > >> > >> *)ospfv3IfTable > >> > > > > NIT: REFERENCE clause "parameters parameters", please > > change to "parameters" > > > > > > > > > > *) ospfv3IfAdminStat > > Please rename to ospfv3IfAdminStatus > > > > > > > > *) Why is there no ospfv3IfOperStatus object? > > Typically, the AdminStatus if for setting and > > the OperStatus is used to read if the status > > changes. I think both would be appropriate here. > > Please comment. > > > > > > > >> > >> > >> *) ospfv3NbrTable and ospfv3CfgNbrTable > >> > >> What is the relationship between these 2 tables? > >> The indexing is different between the 2 tables and so > >> I'm wondering what the relationship is between them. > >> > > > > So to restate my question, there is an ospfv3CfgNbrEntry which is > > a single neighbor that has been configured and there is > > an ospfv3NbrEntry which contains info about a single neighbor, so > > does the ospfv3CfgNbrEntry also have an associated ospfv3NbrEntry? > > > > If so, can some explanation be given on how to look up a > > related entry in the ospfv3NbrEntry table once the=20 > ospfv3CfgNbrEntry is > > populated? > > > > If there is no relationship between these two tables then > > please state that in the DESCRIPTION clauses for the tables. > > > > > > > > *) ospfv3NbrRtrId > > > > NIT: says "32-bit integer" and should be "32-bit unsigned integer" > > > > > >> > >> > >> > >> Notifications > >> ------------ > >> > >> In general the accessible-for-notify objects should probably be > >> changed into read-only objects. Additionally, a timestamp should > >> be associated with some of these. There is an assumption made that > >> it is better to send out notifications rather than poll, but I'd > >> rather give the operator the choice on that. > >> > >> > > > > Please comment. > > > > *) ospfv3PacketSrc > > > > Same sort of issue as discussed in the General Comment Section > > above. This one especially mentions returning 0, but it is an > > InetAddressIPv6 which has OCTET STRING (SIZE (16)) > > so please clarify what is expected by the agent. > > > > > >> > >> Compliance Statements > >> ------------------------- > >> > > > > *) NIT: ospfv3Compliance should be renamed to > > ospfv3FullCompliance > > > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf=20 >=20 >=20 From acee@redback.com Sat Feb 14 13:43:45 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 56B833A6825 for ; Sat, 14 Feb 2009 13:43:45 -0800 (PST) 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 F5BTO9kkCtVe for ; Sat, 14 Feb 2009 13:43:44 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id A43703A6816 for ; Sat, 14 Feb 2009 13:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D98B920175A for ; Sat, 14 Feb 2009 13:43:52 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25041-03 for ; Sat, 14 Feb 2009 13:43:52 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 94C52201759 for ; Sat, 14 Feb 2009 13:43:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: OSPF List From: Acee Lindem Date: Sat, 14 Feb 2009 16:43:50 -0500 X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] OSPF Multi-Instance and Transport Instance 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, 14 Feb 2009 21:43:45 -0000 In Minneapolis, there was some interest in making these WG group documents. Additionally, the AD have sponsored this activity given that a solution is being actively pursued in the ISIS WG (though significantly less powerful). There was one dissenting comment that one could achieve the same results with a single instance given sufficient invention (aka, the "even pigs can fly" argument). I've added text to the transport instance draft as well as mechanisms and text enabling sparse topologies that I believe clearly demonstrates the superiority of this solution. Hence, I like to now ask if there is any further reason not to make these WG documents? Here are the current versions: http://www.ietf.org/internet-drafts/draft-acee-ospf-multi- instance-02.txt http://www.ietf.org/internet-drafts/draft-acee-ospf-transport- instance-02.txt Thanks, Acee From Dimitri.Papadimitriou@alcatel-lucent.be Sun Feb 15 02:18:30 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 03D293A693D for ; Sun, 15 Feb 2009 02:18:30 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 d4yHYe6AKXJW for ; Sun, 15 Feb 2009 02:18:29 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id DDC7E3A690D for ; Sun, 15 Feb 2009 02:18:27 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1FAIRJ4001342; Sun, 15 Feb 2009 11:18:32 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 15 Feb 2009 11:18:27 +0100 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: Sun, 15 Feb 2009 11:18:38 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801C144DB@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF Multi-Instance and Transport Instance Thread-Index: AcmO7WAy1n2VmT9lQaysepK7gIWPkgAFSKtQ References: From: "PAPADIMITRIOU Dimitri" To: "Acee Lindem" , "OSPF List" X-OriginalArrivalTime: 15 Feb 2009 10:18:27.0726 (UTC) FILETIME=[BE2BA2E0:01C98F56] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance 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: Sun, 15 Feb 2009 10:18:30 -0000 pls, re-read your meeting minutes.=20 The first issue is: fixed segmentation of resources between instances processing non-opaque and opaque LSAs is less robust than a flexible sharing of these resources assuming events triggering opaque and non-opaque LSAs (used indirectly by some application) are independent. The assumption of correlation (opaque LSAs directly processed by OSPF) is left possible by RFC 2740. Nevertheless, this draft does not isolate the "IP Routing instance" from the latter LSAs. The second issue is: i) the proposal moves from multiplexed exchanges to serialized exchanges of LS PDUs between peering instances of opaques and non-opaque LSAs, ii) the messaging between different instances still share the same links and header processing (note: by definition instances are "co-located") but are under the control of different instances thus requiring further prioritization at the sender side. Thus, the current proposal further constraints the sender's instances to expectedly prevent overloading the receiver. This is made possible by putting down to the OSPF header (instead of the LSA header) the information with which prioritization at the sender would be possible. Nevertheless, is that not strictly equivalent to prioritize on the LSA header when the instances are common i.e. the draft adds an identifier because it puts processing down the OSPF header. The result is not different from what would be possible using the "Opaque Type" (in combination with the LS Type) since it is only for a sub-class of Opaque LSA (those that are not directly processed by OSPF) that the issue of overloading expectedly arises. -d. =20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Acee Lindem > Sent: Saturday, February 14, 2009 10:44 PM > To: OSPF List > Subject: [OSPF] OSPF Multi-Instance and Transport Instance >=20 > In Minneapolis, there was some interest in making these WG group =20 > documents. Additionally, the AD have sponsored this activity given =20 > that a solution is being actively pursued in the ISIS WG (though =20 > significantly less powerful). >=20 > There was one dissenting comment that one could achieve the same =20 > results with a single instance given sufficient invention (aka, the =20 > "even pigs can fly" argument). I've added text to the transport =20 > instance draft as well as mechanisms and text enabling sparse =20 > topologies that I believe clearly demonstrates the superiority of =20 > this solution. Hence, I like to now ask if there is any further =20 > reason not to make these WG documents? >=20 > Here are the current versions: >=20 > http://www.ietf.org/internet-drafts/draft-acee-ospf-multi-=20 > instance-02.txt > http://www.ietf.org/internet-drafts/draft-acee-ospf-transport-=20 > instance-02.txt >=20 > Thanks, > Acee=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 From nsheth@juniper.net Mon Feb 16 18:51:07 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 0F2213A6AF7 for ; Mon, 16 Feb 2009 18:51:07 -0800 (PST) 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 BmWuVYzcJ8MN for ; Mon, 16 Feb 2009 18:51:06 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 39C5F3A69B8 for ; Mon, 16 Feb 2009 18:51:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSZomF1remsvFHm30fLniD7wDP+MfuAJX@postini.com; Mon, 16 Feb 2009 18:51:17 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 16 Feb 2009 18:49:08 -0800 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, 16 Feb 2009 18:49:08 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Feb 2009 18:49:09 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 18:49:08 -0800 Received: from [127.0.0.1] (sa-nc-spg-18.static.jnpr.net [172.23.1.18]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1H2n8M56075 for ; Mon, 16 Feb 2009 18:49:08 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <499A25A5.50308@juniper.net> Date: Mon, 16 Feb 2009 18:49:09 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "ospf@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2009 02:49:08.0428 (UTC) FILETIME=[4E00B8C0:01C990AA] Subject: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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, 17 Feb 2009 02:51:07 -0000 I have a question about originating a type 4 summary LSA when a router has an intra-area route (via area A) to an ASBR as well as a lower cost inter-area route (via the backbone) to the same ASBR through another ABR. According to the sixth bullet in section 12.4.3 of RFC 2328: Else, if the destination of this route is an AS boundary router, a summary-LSA should be originated if and only if the routing table entry describes the preferred path to the AS boundary router (see Step 3 of Section 16.4). If so, a Type 4 summary-LSA is originated for the destination, with Link State ID equal to the AS boundary router's Router ID and metric equal to the routing table entry's cost. Note: these LSAs should not be generated if Area A has been configured as a stub area. According to section 16.4 item (3), the preferred route to the ASBR would be the least cost route i.e. the inter-area route, since RFC1583Compatibility is enabled. Thus, as far as I can tell, we would generate a type 4 summary when processing the inter-area route entry and advertise the summary into area A and not generate the corresponding summary into the backbone. This would be different than RFC 1583 behavior or RFC 2328 behavior with RFC1583Compatibility disabled. In those two cases, we would generate a type 4 summary into the backbone and areas other than A when processing the intra-area route entry, since the intra-area route would be the preferred route. Is this the correct interpretation of sections 12.4.3 and 16.4? Thanks in advance for any responses. -Nischal From acee@redback.com Tue Feb 17 07:06: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 4FC0B3A6C1B for ; Tue, 17 Feb 2009 07:06:16 -0800 (PST) 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 Mk315ZSj0LLS for ; Tue, 17 Feb 2009 07:06:15 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 60FBC3A693F for ; Tue, 17 Feb 2009 07:06:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id CFF3A433330; Tue, 17 Feb 2009 07:06:26 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29108-03; Tue, 17 Feb 2009 07:06:26 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 378C7433337; Tue, 17 Feb 2009 07:06:26 -0800 (PST) In-Reply-To: <00275A5B436CA441900CB10936742A3801C144DB@FRVELSMBS22.ad2.ad.alcatel.com> References: <00275A5B436CA441900CB10936742A3801C144DB@FRVELSMBS22.ad2.ad.alcatel.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: Tue, 17 Feb 2009 10:06:24 -0500 To: PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance 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, 17 Feb 2009 15:06:16 -0000 On Feb 15, 2009, at 5:18 AM, PAPADIMITRIOU Dimitri wrote: > > pls, re-read your meeting minutes. > > The first issue is: fixed segmentation of resources between instances > processing non-opaque and opaque LSAs is less robust than a flexible > sharing of these resources assuming events triggering opaque and > non-opaque LSAs (used indirectly by some application) are independent. > The assumption of correlation (opaque LSAs directly processed by OSPF) > is left possible by RFC 2740. Nevertheless, this draft does not > isolate > the "IP Routing instance" from the latter LSAs. > > The second issue is: i) the proposal moves from multiplexed > exchanges to > serialized exchanges of LS PDUs between peering instances of > opaques and > non-opaque LSAs, ii) the messaging between different instances still > share the same links and header processing (note: by definition > instances are "co-located") but are under the control of different > instances thus requiring further prioritization at the sender side. > Thus, the current proposal further constraints the sender's > instances to > expectedly prevent overloading the receiver. This is made possible by > putting down to the OSPF header (instead of the LSA header) the > information with which prioritization at the sender would be possible. > Nevertheless, is that not strictly equivalent to prioritize on the LSA > header when the instances are common i.e. the draft adds an identifier > because it puts processing down the OSPF header. The result is not > different from what would be possible using the "Opaque Type" (in > combination with the LS Type) since it is only for a sub-class of > Opaque > LSA (those that are not directly processed by OSPF) that the issue of > overloading expectedly arises. Section 2.4 addresses IP/IPv6 packet prioritization and many (if not most) commercial routers use the packet precedence for internal prioritization. What more would be required? We could state that the precedence MAY also used for internal prioritization. However, we want to steer clear of implying a specific implementation. Thanks, Acee > > -d. > > >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> Behalf Of Acee Lindem >> Sent: Saturday, February 14, 2009 10:44 PM >> To: OSPF List >> Subject: [OSPF] OSPF Multi-Instance and Transport Instance >> >> In Minneapolis, there was some interest in making these WG group >> documents. Additionally, the AD have sponsored this activity given >> that a solution is being actively pursued in the ISIS WG (though >> significantly less powerful). >> >> There was one dissenting comment that one could achieve the same >> results with a single instance given sufficient invention (aka, the >> "even pigs can fly" argument). I've added text to the transport >> instance draft as well as mechanisms and text enabling sparse >> topologies that I believe clearly demonstrates the superiority of >> this solution. Hence, I like to now ask if there is any further >> reason not to make these WG documents? >> >> Here are the current versions: >> >> http://www.ietf.org/internet-drafts/draft-acee-ospf-multi- >> instance-02.txt >> http://www.ietf.org/internet-drafts/draft-acee-ospf-transport- >> instance-02.txt >> >> Thanks, >> Acee >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> From Dimitri.Papadimitriou@alcatel-lucent.be Wed Feb 18 00:15:25 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 3CE9E3A6C62 for ; Wed, 18 Feb 2009 00:15:25 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 nP9YKXBur2t1 for ; Wed, 18 Feb 2009 00:15:24 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id EC0283A6887 for ; Wed, 18 Feb 2009 00:15:23 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1I8FYF8016784; Wed, 18 Feb 2009 09:15:34 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Feb 2009 09:15:33 +0100 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: Wed, 18 Feb 2009 09:15:36 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801C613B1@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF Multi-Instance and Transport Instance Thread-Index: AcmREVk0cW+GcMPBT9mcDxL/1KlhOQAIIB1A References: <00275A5B436CA441900CB10936742A3801C144DB@FRVELSMBS22.ad2.ad.alcatel.com> From: "PAPADIMITRIOU Dimitri" To: "Acee Lindem" X-OriginalArrivalTime: 18 Feb 2009 08:15:33.0752 (UTC) FILETIME=[122DBF80:01C991A1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: OSPF List Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance 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, 18 Feb 2009 08:15:25 -0000 acee:=20 > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com]=20 > Sent: Tuesday, February 17, 2009 4:06 PM > To: PAPADIMITRIOU Dimitri > Cc: OSPF List > Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance >=20 >=20 > On Feb 15, 2009, at 5:18 AM, PAPADIMITRIOU Dimitri wrote: >=20 > > > > pls, re-read your meeting minutes. > > > > The first issue is: fixed segmentation of resources between=20 > instances > > processing non-opaque and opaque LSAs is less robust than a flexible > > sharing of these resources assuming events triggering opaque and > > non-opaque LSAs (used indirectly by some application) are=20 > independent. > > The assumption of correlation (opaque LSAs directly=20 > processed by OSPF) > > is left possible by RFC 2740. Nevertheless, this draft does not =20 > > isolate > > the "IP Routing instance" from the latter LSAs. > > > > The second issue is: i) the proposal moves from multiplexed =20 > > exchanges to > > serialized exchanges of LS PDUs between peering instances of =20 > > opaques and > > non-opaque LSAs, ii) the messaging between different instances still > > share the same links and header processing (note: by definition > > instances are "co-located") but are under the control of different > > instances thus requiring further prioritization at the sender side. > > Thus, the current proposal further constraints the sender's =20 > > instances to > > expectedly prevent overloading the receiver. This is made=20 > possible by > > putting down to the OSPF header (instead of the LSA header) the > > information with which prioritization at the sender would=20 > be possible. > > Nevertheless, is that not strictly equivalent to prioritize=20 > on the LSA > > header when the instances are common i.e. the draft adds an=20 > identifier > > because it puts processing down the OSPF header. The result is not > > different from what would be possible using the "Opaque Type" (in > > combination with the LS Type) since it is only for a sub-class of =20 > > Opaque > > LSA (those that are not directly processed by OSPF) that=20 > the issue of > > overloading expectedly arises. >=20 > Section 2.4 addresses IP/IPv6 packet prioritization and many (if not =20 > most) commercial routers use the packet precedence for internal =20 > prioritization. What more would be required? We could state that the =20 > precedence MAY also used for internal prioritization. However, we =20 > want to steer clear of implying a specific implementation. The point here is that this notion of "instance ID" is not meant to solve any "overload" problem it is primarily a separation of instances for administrative and policy reasons. Any of them are instances exchanges LSAs and Opaque LSAs. In the present case, the problem - that i perfectly acknowledge - is resulting from the dual use of Opaque LSAs wrt other LSA exchanges whereas the instance ID does not assume such separation.=20 Thanks, -dimitri. > Thanks, > Acee >=20 >=20 > > > > -d. > > > > > >> -----Original Message----- > >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > >> Behalf Of Acee Lindem > >> Sent: Saturday, February 14, 2009 10:44 PM > >> To: OSPF List > >> Subject: [OSPF] OSPF Multi-Instance and Transport Instance > >> > >> In Minneapolis, there was some interest in making these WG group > >> documents. Additionally, the AD have sponsored this activity given > >> that a solution is being actively pursued in the ISIS WG (though > >> significantly less powerful). > >> > >> There was one dissenting comment that one could achieve the same > >> results with a single instance given sufficient invention (aka, the > >> "even pigs can fly" argument). I've added text to the transport > >> instance draft as well as mechanisms and text enabling sparse > >> topologies that I believe clearly demonstrates the superiority of > >> this solution. Hence, I like to now ask if there is any further > >> reason not to make these WG documents? > >> > >> Here are the current versions: > >> > >> http://www.ietf.org/internet-drafts/draft-acee-ospf-multi- > >> instance-02.txt > >> http://www.ietf.org/internet-drafts/draft-acee-ospf-transport- > >> instance-02.txt > >> > >> Thanks, > >> Acee > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www.ietf.org/mailman/listinfo/ospf > >> >=20 >=20 From achaudhary@huawei.com Wed Feb 18 07:50:36 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 D0DCC3A67B2 for ; Wed, 18 Feb 2009 07:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 fF28oCZ4ePZn for ; Wed, 18 Feb 2009 07:50:36 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C8A5E3A697A for ; Wed, 18 Feb 2009 07:50:35 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KF900J6QQOD3F@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 18 Feb 2009 23:50:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KF9009WYQOCTY@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 18 Feb 2009 23:50:37 +0800 (CST) Received: from HTIPL108071671 ([10.18.23.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KF900H67QOBO3@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 18 Feb 2009 23:50:36 +0800 (CST) Date: Wed, 18 Feb 2009 21:20:34 +0530 From: Abhijit Chaudhary To: ospf@ietf.org Message-id: <000e01c991e0$a3742710$4217120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_yxe1vxeWtDEyBv/e2XMhGQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [OSPF] Multi-topology OSPF, RFC : 4915 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, 18 Feb 2009 15:50:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_yxe1vxeWtDEyBv/e2XMhGQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT I have a question Regarding Section 5 of OSPF-MT < RFC SNIPPET> 5. Interoperability between MT-Capable and Non-MT-Capable Routers The default metric field is mandatory in all LSAs (even when the metric value is 0). Even when a link or prefix does not exist in the default topology, a non-MT router will consider the zero value in the metric field as a valid metric and consider the link or prefix as part of the default topology. In order to prevent the above problem, an MT-capable router will include all links as part of the default topology. If links need to be removed from the default topology, an MT-capable router must be configured in DefaultExclusionCapability mode. In this mode, routers will ensure that all other routers in the area are in the DefaultExclusionCapability mode before considering the MT-ID#0 metric in the SPF calculation. Only then can the TOS 0 metric field in Router-LSAs be safely ignored during the default topology SPF computation. Now, how does an MT-capable router automatically ensure that all other routers in the same area are also in DefaultExclusionCapability mode? If I understand correctly, one solution can be for the calculating router to ensure that the router-LSAs from all other routers in the area have the MT Option set. But then, it is not mandatory that router-LSAs MUST have MT-bit set. Is there any other solution? Thanks, - Abhijit --Boundary_(ID_yxe1vxeWtDEyBv/e2XMhGQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
I have a question Regarding Section 5 of OSPF-MT
 
< RFC SNIPPET>
5.  Interoperability between MT-Capable and Non-MT-Capable Routers
  The default metric field is mandatory in all LSAs (even when the
   metric value is 0).  Even when a link or prefix does not exist in the
   default topology, a non-MT router will consider the zero value in the
   metric field as a valid metric and consider the link or prefix as
   part of the default topology.

   In order to prevent the above problem, an MT-capable router will
   include all links as part of the default topology.  If links need to
   be removed from the default topology, an MT-capable router must be
   configured in DefaultExclusionCapability mode.  In this mode, routers
   will ensure that all other routers in the area are in the
   DefaultExclusionCapability mode before considering the MT-ID#0 metric
   in the SPF calculation.  Only then can the TOS 0 metric field in
   Router-LSAs be safely ignored during the default topology SPF
   computation.
 
</RFC SNIPPET>
 
Now, how does an MT-capable router automatically ensure that all other routers in the same area are also in DefaultExclusionCapability mode?
If I understand correctly, one solution can be for the calculating router to ensure that the router-LSAs from all other routers in the area have the MT Option set. But then, it is not mandatory that router-LSAs MUST have MT-bit set.
 
Is there any other solution?
 
Thanks,
- Abhijit
 

 --Boundary_(ID_yxe1vxeWtDEyBv/e2XMhGQ)-- From jcucchiara@mindspring.com Wed Feb 18 19:40:21 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 A40793A6A38; Wed, 18 Feb 2009 19:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, MANGLED_ONLINE=2.3] 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 1rNoTKiMd6Kj; Wed, 18 Feb 2009 19:40:20 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id C59453A695B; Wed, 18 Feb 2009 19:40:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pQTXObxxaio4UM5n2l6IyRG6VkN6D75umWzwf1mWOuptipZiG6vk3oKPrZisV6IZ; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.112.219] (helo=JoanPC) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LZzly-00079L-A3; Wed, 18 Feb 2009 22:40:27 -0500 Message-ID: <004a01c99243$cd5bcf20$6401a8c0@JoanPC> From: "Joan Cucchiara" To: "Dan Joyal" References: <001c01c99201$289e5ee0$6401a8c0@JoanPC> Date: Wed, 18 Feb 2009 22:40:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654988c3929ee33cc4fda997d8319a66aca7c7233ee4b332ceb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.112.219 Cc: Vishwas Manral , "MIB Doctors \(E-mail\)" , ospf@ietf.org Subject: Re: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt 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, 19 Feb 2009 03:40:21 -0000 Dan, Think we are down to one or two questions! Thanks, -Joan > > ----- Original Message ----- > From: "Daniel Joyal" > To: "Joan Cucchiara" > Cc: "Vishwas Manral" ; "Acee Lindem" > > Sent: Tuesday, February 17, 2009 5:18 PM > Subject: RE: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt > > > Hi Joan, > > Thanks for your patience in doing the review twice! > See comments and questions in-line. > > Cheers, > -Dan > >> -----Original Message----- >> From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] >> Sent: Wednesday, February 11, 2009 12:47 AM >> To: ospf@ietf.org >> Cc: Dan Romascanu; Abhay Roy; David Ward; Ronald Bonica; >> Joyal, Daniel (BL60:SF23); Vishwas Manral; Acee Lindem >> Subject: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt >> >> >> Dan J. and Vishwas, >> >> First, I do apologize for being late with this review, thank >> you for your patience. >> >> A great deal of work went into this >> latest revision! Thanks for that! >> >> The MIB compilers' outputs are given, >> followed by output from >> IDNITS (http://tools.ietf.org/tools/idnits/) >> followed by comments. >> >> Most all comments are from prior review. Please note, where >> agreement was reached, the comments have been deleted. >> >> Thanks, >> Joan >> >> >> >> smicngPRO output >> ----------------- >> >> W: f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical to >> access specified for "ospfv3StubRouterSupport" >> W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value identical to >> access specified for "ospfv3IfState" >> > > I don't have access to smicngPRO. Is it complaining that > MIN-ACCESS is equal to MAX-ACCESS for these objects? Yes. Please remove the following lines in the conformance section, then these warnings will be resolved: OBJECT ospfv3StubRouterSupport MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfState MIN-ACCESS read-only DESCRIPTION "Write access is not required." > >> >> smlint >> ----------- >> Line Severity Problem >> 3096 5 warning: `InetAddress' should be used instead of >> `InetAddressIPv6' >> > > The message is intended to warn that the IP address is > specific to a particular address family in cases where > the MIB should support multiple address families. > But the OSPFv3 MIB only supports the IPv6 address family. > The OSPFv3 MIB is not compatible with OSPFv2 implementations. > In this case, can the warning be ignored? Yes. > >> >> IDNITS >> ------ >> idnits 2.11.01 >> >> tmp/draft-ietf-ospf-ospfv3-mib-13.txt: >> >> Checking boilerplate required by RFC 5378 and the IETF Trust (see >> http://trustee.ietf.org/license-info): >> >> -------------------------------------------------------------- >> -------------- >> >> ** It looks like you're using RFC 3978 boilerplate. You >> should update this >> to the boilerplate described in the IETF Trust License >> Policy document >> (see http://trustee.ietf.org/license-info), which is >> required from >> December 16, 2008. Version 1.34 of xml2rfc can be used >> to produce >> documents with boilerplate according to the mentioned >> Trust License >> Policy document. >> >> -- Found old boilerplate from RFC 3978 Section 5.1 on line 16. >> >> The obsolete RFC 3978 Section 5.1 text: >> "By submitting this Internet-Draft, each author >> represents that any >> applicable patent or other IPR claims of which he or >> she is aware >> have been or will be disclosed, and any of which he or >> she becomes >> aware will be disclosed, in accordance with Section 6 >> of BCP 79." >> >> -- Found old boilerplate from RFC 3978 Section 5.5 updated >> by RFC 4748 on >> line 4482. >> >> The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text: >> "This document and the information contained herein are >> provided on an >> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET >> SOCIETY, THE >> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL >> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY >> WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL >> NOT INFRINGE >> ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY >> OR FITNESS >> FOR A PARTICULAR PURPOSE." >> >> -- Found old boilerplate from RFC 3979 Section 5 paragraph >> 1 on line 4493. >> >> The obsolete RFC 3979 Section 5 paragraph 1 text: >> "The IETF takes no position regarding the validity or >> scope of any >> Intellectual Property Rights or other rights that might >> be claimed >> to pertain to the implementation or use of the >> technology described >> in this document or the extent to which any license under such >> rights might or might not be available; nor does it >> represent that >> it has made any independent effort to identify any such rights. >> Information on the procedures with respect to rights in RFC >> documents can be found in BCP 78 and BCP 79." >> >> -- Found old boilerplate from RFC 3979 Section 5 paragraph >> 2 on line 4500. >> >> The obsolete RFC 3979 Section 5 paragraph 2 text: >> "Copies of IPR disclosures made to the IETF Secretariat and any >> assurances of licenses to be made available, or the result of an >> attempt made to obtain a general license or permission >> for the use >> of such proprietary rights by implementers or users of this >> specification can be obtained from the IETF on-line IPR >> repository >> at http://www.ietf.org/ipr." >> >> -- Found old boilerplate from RFC 3979 Section 5 paragraph >> 3 on line 4506. >> >> The obsolete RFC 3979 Section 5 paragraph 3 text: >> "The IETF invites any interested party to bring to its >> attention any >> copyrights, patents or patent applications, or other proprietary >> rights that may cover technology that may be required >> to implement >> this standard. Please address the information to the IETF at >> ietf-ipr@ietf.org." >> >> >> Checking nits according to >> http://www.ietf.org/ietf/1id-guidelines.txt: >> >> -------------------------------------------------------------- >> -------------- >> >> No issues found here. >> >> Checking nits according to http://www.ietf.org/ID-Checklist.html: >> >> -------------------------------------------------------------- >> -------------- >> >> No issues found here. >> >> Miscellaneous warnings: >> >> -------------------------------------------------------------- >> -------------- >> >> == The copyright year in the IETF Trust Copyright Line does >> not match the >> current year >> >> >> Checking references for intended status: Proposed Standard >> >> -------------------------------------------------------------- >> -------------- >> >> (See RFCs 3967 and 4897 for information about using >> normative references >> to lower-maturity documents in RFCs) >> >> No issues found here. >> >> Summary: 1 error (**), 1 warning (==), 5 comments (--). >> >> >> ------------- >> > > The boilerplate requirements changed after the last revision > was posted. I will update the boilerplate such that no > ID_NIT issues are raised. Thanks! > >> > >> > >> > General Comments >> > ----------------- >> > >> > 1) Need to have a read-only conformance. >> >> (NEW) NIT: would change the name from >> ospfv3Compliance to ospfv3FullCompliance. > > Will change. > >> >> >> > >> > 5) The MIB did not extract using mstrip (MIB tool). >> > If possible, could this be fixed? >> >> This is a NIT, but still had trouble with mstrip tool. > > Does the tool take the standard ascii text file as input? > I'll try to find a user guide for the tool to see what it > is expecting regarding file formatting. > I mention this as an FYI. You do not need fix this for MIB DR review. As I recall, the RFC Editor has fixed this kind of formatting issue in the past. >> >> >> >> 6) NEW: Use of InetAddressType and InetAddress In several >> places in the MIB, the DESCRIPTION states something like >> "only IPv6 global address type expected" and then InetAddress >> (SIZE (16)) is given. >> >> First, I have to ask if this is truly the intention or would >> having {unknown(0), ipv6(2) } and (SIZE (0|16)) be more appropriate. > > How would an implementation behave for an unknown(0) address type? For this MIB, unknown(0) could be a placeholder as Rows were being created, until the real values became available (e.g. depends on how rows were created, or how an agent fills in the info from a cfg file during restarts). This would not be appropriate for InetAddressType that was part of the Index. In this MIB, it might be appropriate for ospfv3VirtNbrAddressType until the actual value was available (e.g. for implementations that don't have all the information available at once during agent start/restart). To state my question another way, would adding Unknown and SIZE(0) as options be helpful (or provide more flexibility) for implementations? If the answer is no, then don't add it, if the answer is yes, then would seem appropriate to add it. I'm not suggesting that this be added, only asking the question. > >> >> >> Second, you restrict InetAddress at the object, but the >> InetAddressType as part of the conformance. Could you please >> choose one place or the other? >> >> I tend to prefer these restrictions be in the conformance >> section because it is slightly less painful to revise the >> conformance section, than to revise objects (but this is >> just my opinion). >> At any rate, would ask that you be consistent so restrict >> both InetAddressType and InetAddress either in the object's >> SYNTAX or add to the Conformance Section. > > OK. I'll restrict in conformance section. Thanks. > >> >> >> >> >> >> > >> > >> > Comments in Order of the document >> > ---------------------------------- >> > >> >> >> (NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC to be >> consistent with the names of the other TCs. >> > > Will change. > >> >> >> > >> > *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this >> table may >> > have a DEFVAL clause of zero (this is mentioned in the DESCRIPTION >> > clauses). >> > >> >> Not Done. Even though these are read-only objects, the >> DEFVAL helps Agent developers so would add this, unless there >> is a reason not to. >> > > Will add DEFVAL. > >> > *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown) >> > >> > Please indicate what true(1) means in the DESCRIPTION >> > >> >> Not Done. > > Will add. > >> >> >> >> >> > >> > *) ospfv3HostTable >> > >> > Need to have a storageType object added to this table. >> > >> >> Sorry, I was not correct when I said that a storageType was >> needed. The MIB Guidelines specifies to either add a >> storageType object OR add a description to the Entry (as you >> have done in other >> Tables.) To quote from rfc4181: >> >> - "There either MUST be one columnar object with a >> SYNTAX value of >> StorageType [RFC2579] and a MAX-ACCESS value of read-create, or >> else the row object (table entry) DESCRIPTION clause >> MUST specify >> what happens to dynamically-created rows after an >> agent restart." >> >> >> >> In any case, the description in the StorageType object >> conflicts with the Table's description. >> >> Also, if the agent is able to create/delete rows then this >> needs to be documented...(from rfc4181): >> >> -"If the agent itself may also create and/or delete >> rows, then the >> conditions under which this can occur MUST be clearly >> documented >> in the row object DESCRIPTION clause." >> >> >> Please clarify. >> > > Does your comment apply to this table only? Can I remove the > StorageType object and add to Description clause as was done > with other tables? Yes. > Are the Description clauses for other > like tables acceptible for this table? > Yes. >> >> > >> > >> > >> > >> > *) ospfv3HostEntry and ospfv3HostStorageType >> > >> >> Same comment as above. >> > > Same questions as above. > >> >> >> > >> > *)ospfv3IfTable >> > >> >> NIT: REFERENCE clause "parameters parameters", please change >> to "parameters" >> > > Will change. > >> >> >> >> *) ospfv3IfAdminStat >> Please rename to ospfv3IfAdminStatus >> > > Will change. Should also have asked about ospfv3AdminStat (the scalar) also. Could you rename this to ospfv3AdminStatus? Also, if the ospfv3IfAdminStatus is enabled, but the ospfv3AdminStatus (scalar) is disabled, then does this mean that all the interfaces behave as if they are disabled? In other words, does the scalar (ospfv3AdminStatus) takes precedence over the individual interface's ospfv3IfAdminStatus value? If so, could you please add a mention of this to the description of ospfv3IfAdminStatus and also ospfv3IfState? > >> >> >> *) Why is there no ospfv3IfOperStatus object? >> Typically, the AdminStatus if for setting and the OperStatus >> is used to read if the status changes. I think both would be >> appropriate here. >> Please comment. >> > > The object ospfv3IfState gives the operational state of the > OSPF interface. Okay, please add a Reference for this. As mentioned above in the discussion of ospfv3IfAdminStatus, please expand the description clause to mention how the adminStatuses effect this object. > >> >> >> > >> > >> > *) ospfv3NbrTable and ospfv3CfgNbrTable >> > >> > What is the relationship between these 2 tables? >> > The indexing is different between the 2 tables and so I'm wondering >> > what the relationship is between them. >> > >> >> So to restate my question, there is an ospfv3CfgNbrEntry >> which is a single neighbor that has been configured and there >> is an ospfv3NbrEntry which contains info about a single >> neighbor, so does the ospfv3CfgNbrEntry also have an >> associated ospfv3NbrEntry? > > Yes it does. Configured neighbors are used when running OSPF > on NBMA subnets (OSPF nbma and point-to-multipoint link types). > The configured neighbors table just gives OSPF information > for sending hellos to potential neighbors. Once a hello is > received from a neighbor in the configured neighbor table, > an entry for that neighbor is created in the neighbor table > and adjacency state is maintained there. Neighbors on multi-access > or point-to-point subnets can use multicast addressing, so > only neighbor table entries are created. > >> >> If so, can some explanation be given on how to look up a >> related entry in the ospfv3NbrEntry table once the >> ospfv3CfgNbrEntry is populated? > > OK. I will better describe the relationship between > the tables. Thanks for the clarification. If you can include in these table DESCRIPTIONs what you explained above, that would be great. > >> >> If there is no relationship between these two tables then >> please state that in the DESCRIPTION clauses for the tables. >> >> >> >> *) ospfv3NbrRtrId >> >> NIT: says "32-bit integer" and should be "32-bit unsigned integer" > > Will change. > >> >> >> > >> > >> > >> > Notifications >> > ------------ >> > >> > In general the accessible-for-notify objects should probably be >> > changed into read-only objects. Additionally, a timestamp >> should be >> > associated with some of these. There is an assumption made >> that it is >> > better to send out notifications rather than poll, but I'd >> rather give >> > the operator the choice on that. >> > >> > >> >> Please comment. > > I've seen accessible-for-notify used in other MIBs, but I defer > to your expert judgement on this. Which objects to you think > need a timestamp? > Dan, Sorry I made a mistake here. I think I didn't quite understand how these accessible-for-notify objects were used in several notifications, but now I see, so timestamps don't make sense, neither does changing these objects to read-only. Please leave them as accessible-for-notify BUT please also modify the DESCRIPTION clause which is confusing. Since these are not read-only, please remove the phrase which begins "When the last value...." >> >> *) ospfv3PacketSrc >> >> Same sort of issue as discussed in the General Comment >> Section above. This one especially mentions returning 0, but it is an >> InetAddressIPv6 which has OCTET STRING (SIZE (16)) so please >> clarify what is expected by the agent. > > I believe the text about the zero value is derived from the OSPFv2 MIB > comment by a MIB reviewer. > > ospfPacketSrc OBJECT-TYPE > SYNTAX IpAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The IP address of an inbound packet that cannot > be identified by a neighbor instance. When > the last value of a trap using this object is > needed, but no traps of that type have been sent, > this value pertaining to this object should > be returned as 0.0.0.0." > ::= { ospfTrapControl 4 } > > I thought the same description would apply to OSPFv3, but instead > returning a value of an octet string of all zeros. Does > this make sense? Since the object has a STATUS of accessible-for-notify the above suggestion of modifying the DESCRIPTION clause to remove the "When the last value...." will resolve the issue. If this was a read-only object then either the "all zeros" or using InetAddress SIZE(0 | 16) so that a zero-length octet string would be returned if a read was done of this address but there was not yet a valid value for it. -Joan > >> >> >> > >> > Compliance Statements >> > ------------------------- >> > >> >> *) NIT: ospfv3Compliance should be renamed to ospfv3FullCompliance > > Will change. > >> >> >> >> > From acee@redback.com Thu Feb 19 02:58:45 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 E254F28C213 for ; Thu, 19 Feb 2009 02:58:45 -0800 (PST) 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 U6Y+tKyGhPTZ for ; Thu, 19 Feb 2009 02:58:45 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 1E99428C20C for ; Thu, 19 Feb 2009 02:58:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AAD9EB21C56; Thu, 19 Feb 2009 02:58:58 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09898-05; Thu, 19 Feb 2009 02:58:58 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 12055B21C55; Thu, 19 Feb 2009 02:58:57 -0800 (PST) In-Reply-To: <499A25A5.50308@juniper.net> References: <499A25A5.50308@juniper.net> 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, 19 Feb 2009 05:58:57 -0500 To: Nischal Sheth X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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, 19 Feb 2009 10:58:46 -0000 Hi Nischal, I think this certainly is ambiguous as to whether the route type should be taken into consideration when determining the which ASBR path is lowest cost. Your literal interpretation seems but reasonable but I know of at least one implementation that would consider the route type. Luckily, this confusion is eliminated if RFC1583Compatiblity is disabled. Thanks, Acee On Feb 16, 2009, at 9:49 PM, Nischal Sheth wrote: > > I have a question about originating a type 4 summary > LSA when a router has an intra-area route (via area A) to > an ASBR as well as a lower cost inter-area route (via the > backbone) to the same ASBR through another ABR. > > According to the sixth bullet in section 12.4.3 of RFC 2328: > > Else, if the destination of this route is an AS boundary > router, a summary-LSA should be originated if and only > if the routing table entry describes the preferred path > to the AS boundary router (see Step 3 of Section 16.4). > If so, a Type 4 summary-LSA is originated for the > destination, with Link State ID equal to the AS boundary > router's Router ID and metric equal to the routing table > entry's cost. Note: these LSAs should not be generated > if Area A has been configured as a stub area. > > According to section 16.4 item (3), the preferred route to > the ASBR would be the least cost route i.e. the inter-area > route, since RFC1583Compatibility is enabled. > > Thus, as far as I can tell, we would generate a type 4 > summary when processing the inter-area route entry and > advertise the summary into area A and not generate the > corresponding summary into the backbone. This would be > different than RFC 1583 behavior or RFC 2328 behavior > with RFC1583Compatibility disabled. In those two cases, > we would generate a type 4 summary into the backbone and > areas other than A when processing the intra-area route > entry, since the intra-area route would be the preferred > route. > > Is this the correct interpretation of sections 12.4.3 and > 16.4? > > Thanks in advance for any responses. > > -Nischal > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nsheth@juniper.net Thu Feb 19 12:58:21 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 1A1F228C0FC for ; Thu, 19 Feb 2009 12:58:21 -0800 (PST) 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 RjcbLfUZpcQq for ; Thu, 19 Feb 2009 12:58:20 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 15F703A696A for ; Thu, 19 Feb 2009 12:58:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ3H5WSlav8vGq7JrjG4AsYyx33I6xUY@postini.com; Thu, 19 Feb 2009 12:58:34 PST 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.340.0; Thu, 19 Feb 2009 12:57:39 -0800 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, 19 Feb 2009 12:57:39 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 12:57:39 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 12:57:38 -0800 Received: from [172.24.24.189] (tdeng-t61.jnpr.net [172.24.24.189] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1JKvcM06174; Thu, 19 Feb 2009 12:57:38 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <499DC76D.9020607@juniper.net> Date: Thu, 19 Feb 2009 12:56:13 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Acee Lindem References: <499A25A5.50308@juniper.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Feb 2009 20:57:38.0705 (UTC) FILETIME=[B2C9A010:01C992D4] Cc: "ospf@ietf.org" Subject: Re: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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, 19 Feb 2009 20:58:21 -0000 Hi Acee, Thanks for the response. I have a related question about the intent of the RFC1583Compatibility global parameter. When set to enabled, is the underlying objective to emulate a RFC 1583 implementation (w.r.t. path selection among ASBRs and external LSAs) or is it "just" to allow compatible operation with other 1583 routers in the network. IOW, does an implementation even need to maintain multiple routes to an ASBR if RFC1583Compatibility is enabled? Thanks, Nischal Acee Lindem wrote: > Hi Nischal, > I think this certainly is ambiguous as to whether the route type should > be taken into consideration when determining the which ASBR path is > lowest cost. Your literal interpretation seems but reasonable but I know > of at least one implementation that would consider the route type. > Luckily, this confusion is eliminated if RFC1583Compatiblity is disabled. > Thanks, > Acee > > On Feb 16, 2009, at 9:49 PM, Nischal Sheth wrote: > >> >> I have a question about originating a type 4 summary >> LSA when a router has an intra-area route (via area A) to >> an ASBR as well as a lower cost inter-area route (via the >> backbone) to the same ASBR through another ABR. >> >> According to the sixth bullet in section 12.4.3 of RFC 2328: >> >> Else, if the destination of this route is an AS boundary >> router, a summary-LSA should be originated if and only >> if the routing table entry describes the preferred path >> to the AS boundary router (see Step 3 of Section 16.4). >> If so, a Type 4 summary-LSA is originated for the >> destination, with Link State ID equal to the AS boundary >> router's Router ID and metric equal to the routing table >> entry's cost. Note: these LSAs should not be generated >> if Area A has been configured as a stub area. >> >> According to section 16.4 item (3), the preferred route to >> the ASBR would be the least cost route i.e. the inter-area >> route, since RFC1583Compatibility is enabled. >> >> Thus, as far as I can tell, we would generate a type 4 >> summary when processing the inter-area route entry and >> advertise the summary into area A and not generate the >> corresponding summary into the backbone. This would be >> different than RFC 1583 behavior or RFC 2328 behavior >> with RFC1583Compatibility disabled. In those two cases, >> we would generate a type 4 summary into the backbone and >> areas other than A when processing the intra-area route >> entry, since the intra-area route would be the preferred >> route. >> >> Is this the correct interpretation of sections 12.4.3 and >> 16.4? >> >> Thanks in advance for any responses. >> >> -Nischal >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > From acee@redback.com Sun Feb 22 06:34: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 52D9928C10F for ; Sun, 22 Feb 2009 06:34:57 -0800 (PST) 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=[AWL=0.000, 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 UPq0+c7B88AM for ; Sun, 22 Feb 2009 06:34:56 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 7894528C128 for ; Sun, 22 Feb 2009 06:34:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9252B20600A; Sun, 22 Feb 2009 06:35:13 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19859-03; Sun, 22 Feb 2009 06:35:13 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 2D015206007; Sun, 22 Feb 2009 06:35:13 -0800 (PST) In-Reply-To: <499DC76D.9020607@juniper.net> References: <499A25A5.50308@juniper.net> <499DC76D.9020607@juniper.net> 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: Sun, 22 Feb 2009 09:35:11 -0500 To: Nischal Sheth X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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: Sun, 22 Feb 2009 14:34:57 -0000 Hi Nischal, On Feb 19, 2009, at 3:56 PM, Nischal Sheth wrote: > > Hi Acee, > > Thanks for the response. > > I have a related question about the intent of the RFC1583Compatibility > global parameter. When set to enabled, is the underlying objective to > emulate a RFC 1583 implementation (w.r.t. path selection among > ASBRs and > external LSAs) or is it "just" to allow compatible operation with > other > 1583 routers in the network. Offhand, I don't see much difference but I might be missing something. > IOW, does an implementation even need to > maintain multiple routes to an ASBR if RFC1583Compatibility is > enabled? I went back to RFC 1583 and a path per area providing ASBR reachability is still maintained. I believe an implementation could maintain a single path but then you'd have to handle finding an alternate path when an ASBR becomes unreachabile. Thanks, Acee > > Thanks, > Nischal > > Acee Lindem wrote: >> Hi Nischal, >> I think this certainly is ambiguous as to whether the route type >> should be taken into consideration when determining the which ASBR >> path is lowest cost. Your literal interpretation seems but >> reasonable but I know of at least one implementation that would >> consider the route type. Luckily, this confusion is eliminated if >> RFC1583Compatiblity is disabled. >> Thanks, >> Acee >> On Feb 16, 2009, at 9:49 PM, Nischal Sheth wrote: >>> >>> I have a question about originating a type 4 summary >>> LSA when a router has an intra-area route (via area A) to >>> an ASBR as well as a lower cost inter-area route (via the >>> backbone) to the same ASBR through another ABR. >>> >>> According to the sixth bullet in section 12.4.3 of RFC 2328: >>> >>> Else, if the destination of this route is an AS boundary >>> router, a summary-LSA should be originated if and only >>> if the routing table entry describes the preferred path >>> to the AS boundary router (see Step 3 of Section 16.4). >>> If so, a Type 4 summary-LSA is originated for the >>> destination, with Link State ID equal to the AS boundary >>> router's Router ID and metric equal to the routing table >>> entry's cost. Note: these LSAs should not be generated >>> if Area A has been configured as a stub area. >>> >>> According to section 16.4 item (3), the preferred route to >>> the ASBR would be the least cost route i.e. the inter-area >>> route, since RFC1583Compatibility is enabled. >>> >>> Thus, as far as I can tell, we would generate a type 4 >>> summary when processing the inter-area route entry and >>> advertise the summary into area A and not generate the >>> corresponding summary into the backbone. This would be >>> different than RFC 1583 behavior or RFC 2328 behavior >>> with RFC1583Compatibility disabled. In those two cases, >>> we would generate a type 4 summary into the backbone and >>> areas other than A when processing the intra-area route >>> entry, since the intra-area route would be the preferred >>> route. >>> >>> Is this the correct interpretation of sections 12.4.3 and >>> 16.4? >>> >>> Thanks in advance for any responses. >>> >>> -Nischal >>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf > From nsheth@juniper.net Sun Feb 22 22:13: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 87E983A6832 for ; Sun, 22 Feb 2009 22:13:23 -0800 (PST) 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 xlveuxbPWDpo for ; Sun, 22 Feb 2009 22:13:22 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id B7C6D3A67A1 for ; Sun, 22 Feb 2009 22:13:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSaI+fvsMYbkwL7/pCL3Mx5WHBMJ5GcNa@postini.com; Sun, 22 Feb 2009 22:13:40 PST 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.340.0; Sun, 22 Feb 2009 22:02:51 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 22:02:51 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 22:02:50 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Feb 2009 22:02:50 -0800 Received: from [127.0.0.1] (securepptp014.static.jnpr.net [172.24.253.14]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1N62oM86963; Sun, 22 Feb 2009 22:02:50 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <49A23C08.2060705@juniper.net> Date: Sun, 22 Feb 2009 22:02:48 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Acee Lindem References: <499A25A5.50308@juniper.net> <499DC76D.9020607@juniper.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2009 06:02:50.0329 (UTC) FILETIME=[5BAC9490:01C9957C] Cc: "ospf@ietf.org" Subject: Re: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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, 23 Feb 2009 06:13:23 -0000 Acee Lindem wrote: > >> IOW, does an implementation even need to >> maintain multiple routes to an ASBR if RFC1583Compatibility is enabled? > > I went back to RFC 1583 and a path per area providing ASBR reachability > is still maintained. I believe an implementation could maintain a single > path but then you'd have to handle finding an alternate path when an > ASBR becomes unreachabile. > Hi Acee, I based this on my reading of section 16.2 in RFC 1583. According to items (5), (6), (7) we only need to maintain the lowest cost route(s) to the ASBR, preferring intra-area routes over inter-area routes. Specifically, item 5 does not say (unlike RFC 2328) to lookup the area specific route entry to N for type 4 LSAs. Hence I figured that we would end up with only 1 route to the ASBR, assuming non equal cost routes. Thanks, Nischal From rameshbabuy@huawei.com Mon Feb 23 03:22: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 230923A698F for ; Mon, 23 Feb 2009 03:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 WngqXlzriaZl for ; Mon, 23 Feb 2009 03:22:05 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BEB243A6874 for ; Mon, 23 Feb 2009 03:22:04 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFI00J27NL8BQ@szxga03-in.huawei.com> for ospf@ietf.org; Mon, 23 Feb 2009 19:22:20 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFI006RHNL882@szxga03-in.huawei.com> for ospf@ietf.org; Mon, 23 Feb 2009 19:22:20 +0800 (CST) Received: from ramesh70952 ([10.18.23.150]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFI00083NL6ZY@szxml06-in.huawei.com> for ospf@ietf.org; Mon, 23 Feb 2009 19:22:20 +0800 (CST) Date: Mon, 23 Feb 2009 16:52:17 +0530 From: rameshbabuy To: ospf@ietf.org Message-id: <003801c995a8$fd987040$9617120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_EoSX8bCbm1LHO1bHRH4paQ)" Thread-index: AcmVqPwmaA62EX34Rqeu4OKGt6tofQ== Subject: [OSPF] Doubt regarding Next hops X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rameshbabuy@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:22:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EoSX8bCbm1LHO1bHRH4paQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi OSPF Group, Kindly explain why can't we load balance next hops across area in case of equi-cost paths? 16.8. Equal-cost multipath The OSPF protocol maintains multiple equal-cost routes to all destinations. This can be seen in the steps used above to calculate the routing table, and in the definition of the routing table structure. Each one of the multiple routes will be of the same type (intra-area, inter-area, type 1 external or type 2 external), cost, and will have the same associated area. However, each route may specify a separate next hop and Advertising router. Regards, Ramesh **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_EoSX8bCbm1LHO1bHRH4paQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi OSPF Group,

Kindly explain why can’t we load balance next hops across area in case of equi-cost paths?

 

    16.8.  Equal-cost multipath

 

        The OSPF protocol maintains multiple equal-cost routes to all

        destinations.  This can be seen in the steps used above to

        calculate the routing table, and in the definition of the

        routing table structure.

 

        Each one of the multiple routes will be of the same type

        (intra-area, inter-area, type 1 external or type 2 external),

        cost, and will have the same associated area.  However, each

        route may specify a separate next hop and Advertising router.

 

Regards,

Ramesh

 

             ***************************************************************************************

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

 

--Boundary_(ID_EoSX8bCbm1LHO1bHRH4paQ)-- From acee@redback.com Mon Feb 23 07:21:53 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 4F80E3A68C2 for ; Mon, 23 Feb 2009 07:21:53 -0800 (PST) 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 Bfw1EMxP6Ayj for ; Mon, 23 Feb 2009 07:21:52 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 9C5A83A6877 for ; Mon, 23 Feb 2009 07:21:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 687CB8F1681; Mon, 23 Feb 2009 07:22:10 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29606-02; Mon, 23 Feb 2009 07:22:10 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 00F918F167D; Mon, 23 Feb 2009 07:22:09 -0800 (PST) In-Reply-To: <49A23C08.2060705@juniper.net> References: <499A25A5.50308@juniper.net> <499DC76D.9020607@juniper.net> <49A23C08.2060705@juniper.net> 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: Mon, 23 Feb 2009 10:22:08 -0500 To: Nischal Sheth X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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, 23 Feb 2009 15:21:53 -0000 Hi Nischal, On Feb 23, 2009, at 1:02 AM, Nischal Sheth wrote: > Acee Lindem wrote: > >>> IOW, does an implementation even need to >>> maintain multiple routes to an ASBR if RFC1583Compatibility is >>> enabled? >> I went back to RFC 1583 and a path per area providing ASBR >> reachability is still maintained. I believe an implementation >> could maintain a single path but then you'd have to handle finding >> an alternate path when an ASBR becomes unreachabile. > > Hi Acee, > > I based this on my reading of section 16.2 in RFC 1583. According > to items > (5), (6), (7) we only need to maintain the lowest cost route(s) to > the ASBR, > preferring intra-area routes over inter-area routes. Specifically, > item 5 does > not say (unlike RFC 2328) to lookup the area specific route entry > to N for > type 4 LSAs. Hence I figured that we would end up with only 1 > route to the > ASBR, assuming non equal cost routes. I agree. Scratch what I said above, I was thinking in terms of an implementation optimization. Thanks, Acee > > Thanks, > Nischal > > From nsheth@juniper.net Mon Feb 23 13:42: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 6A8BA28C15C for ; Mon, 23 Feb 2009 13:42:17 -0800 (PST) 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 C79xr9agD29N for ; Mon, 23 Feb 2009 13:42:16 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 940AE28C168 for ; Mon, 23 Feb 2009 13:42:13 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSaMYMl2zvkUP5MTsIwP+kzpQkbLO97Lf@postini.com; Mon, 23 Feb 2009 13:42:35 PST 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.340.0; Mon, 23 Feb 2009 13:40:36 -0800 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, 23 Feb 2009 13:40:36 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 13:40:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 13:40:35 -0800 Received: from [172.24.24.232] (nsheth-xp-lt.jnpr.net [172.24.24.232]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1NLeYM71790; Mon, 23 Feb 2009 13:40:34 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <49A317CF.5070500@juniper.net> Date: Mon, 23 Feb 2009 13:40:31 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Acee Lindem References: <499A25A5.50308@juniper.net> <499DC76D.9020607@juniper.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2009 21:40:35.0569 (UTC) FILETIME=[5C5EDE10:01C995FF] Cc: "ospf@ietf.org" Subject: Re: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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, 23 Feb 2009 21:42:17 -0000 Acee Lindem wrote: >> >> I have a related question about the intent of the RFC1583Compatibility >> global parameter. When set to enabled, is the underlying objective to >> emulate a RFC 1583 implementation (w.r.t. path selection among ASBRs and >> external LSAs) or is it "just" to allow compatible operation with other >> 1583 routers in the network. > > Offhand, I don't see much difference but I might be missing something. > Hi Acee, Circling back to the original question I posted, my confusion was related to how a RFC 2328 implementation with RFC1583Compatibility enabled should behave as far as picking the best ASBR route is concerned. If you interpret RFC 2328 literally, you would use the lowest cost route to the ASBR irrespective of the type (intra vs. inter). In contrast, an RFC 1583 implementation would prefer the intra-area route. It wasn't clear to me if this difference in behavior is intentional (hence my attempt to differentiate between "compatibility" and "emulation") or whether it's simply the case that the relevant sections are a little bit underspecified. Based on your input, it appears that it's more of the latter than the former. An RFC 2328 implementation can maintain multiple routes to the ASBR but make sure that intra-area routes are preferred when RFC1583Compatibility is enabled. Alternately, it can behave exactly like an RFC 1583 implementation and keep only the intra-area route. Does this sound reasonable? Thanks, Nischal From acee@redback.com Mon Feb 23 14:53:11 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 AB0D13A63D3 for ; Mon, 23 Feb 2009 14:53:11 -0800 (PST) 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=[AWL=0.000, 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 Lu9P2jP2-7WD for ; Mon, 23 Feb 2009 14:53:10 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id C95CA3A6AE9 for ; Mon, 23 Feb 2009 14:53:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 53F99616B26; Mon, 23 Feb 2009 14:53:23 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23428-01; Mon, 23 Feb 2009 14:53:23 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 61B9E616B24; Mon, 23 Feb 2009 14:53:22 -0800 (PST) In-Reply-To: <49A317CF.5070500@juniper.net> References: <499A25A5.50308@juniper.net> <499DC76D.9020607@juniper.net> <49A317CF.5070500@juniper.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AAEB307-B1C1-4BB8-BBEA-D07348E3A02F@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Mon, 23 Feb 2009 17:53:20 -0500 To: Nischal Sheth X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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, 23 Feb 2009 22:53:11 -0000 Hi Nischal, On Feb 23, 2009, at 4:40 PM, Nischal Sheth wrote: > Acee Lindem wrote: > >>> >>> I have a related question about the intent of the >>> RFC1583Compatibility >>> global parameter. When set to enabled, is the underlying >>> objective to >>> emulate a RFC 1583 implementation (w.r.t. path selection among >>> ASBRs and >>> external LSAs) or is it "just" to allow compatible operation with >>> other >>> 1583 routers in the network. >> Offhand, I don't see much difference but I might be missing >> something. >> > > Hi Acee, > > Circling back to the original question I posted, my confusion was > related to > how a RFC 2328 implementation with RFC1583Compatibility enabled > should behave > as far as picking the best ASBR route is concerned. > > If you interpret RFC 2328 literally, you would use the lowest cost > route to > the ASBR irrespective of the type (intra vs. inter). In contrast, > an RFC 1583 > implementation would prefer the intra-area route. It wasn't clear > to me if > this difference in behavior is intentional (hence my attempt to > differentiate > between "compatibility" and "emulation") or whether it's simply the > case that > the relevant sections are a little bit underspecified. > > Based on your input, it appears that it's more of the latter than > the former. > An RFC 2328 implementation can maintain multiple routes to the ASBR > but make > sure that intra-area routes are preferred when RFC1583Compatibility > is enabled. > Alternately, it can behave exactly like an RFC 1583 implementation > and keep > only the intra-area route. > > Does this sound reasonable? Yes. My interpretation of the intent of RFC1583Compatibility is to maintain the RFC 1583 path selection. Thanks, Acee > > Thanks, > Nischal > From nsheth@juniper.net Tue Feb 24 11:48:21 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 B29813A68A7 for ; Tue, 24 Feb 2009 11:48:21 -0800 (PST) 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 rjIKRUBzNsiv for ; Tue, 24 Feb 2009 11:48:20 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id BF0BD3A6403 for ; Tue, 24 Feb 2009 11:48:20 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSaRPCx8rzOgyfVWAyf2eo6lmx94GGzdV@postini.com; Tue, 24 Feb 2009 11:48:40 PST 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.340.0; Tue, 24 Feb 2009 11:45:09 -0800 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, 24 Feb 2009 11:45:09 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 11:45:09 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 11:45:08 -0800 Received: from [127.0.0.1] (sa-nc-spg-31.static.jnpr.net [172.23.1.31]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1OJj5M21186; Tue, 24 Feb 2009 11:45:07 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <49A44E3F.9000806@juniper.net> Date: Tue, 24 Feb 2009 11:45:03 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Acee Lindem References: <499A25A5.50308@juniper.net> <499DC76D.9020607@juniper.net> <49A317CF.5070500@juniper.net> <9AAEB307-B1C1-4BB8-BBEA-D07348E3A02F@redback.com> In-Reply-To: <9AAEB307-B1C1-4BB8-BBEA-D07348E3A02F@redback.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2009 19:45:08.0397 (UTC) FILETIME=[65DE0DD0:01C996B8] Cc: "ospf@ietf.org" Subject: Re: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled 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, 24 Feb 2009 19:48:21 -0000 Acee Lindem wrote: > > Yes. My interpretation of the intent of RFC1583Compatibility is to > maintain the RFC 1583 path selection. > Sounds good. Many thanks for all your input on this thread. -Nischal From acee@redback.com Wed Feb 25 03:13:22 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 954313A6B78 for ; Wed, 25 Feb 2009 03:13:22 -0800 (PST) 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=[AWL=0.000, 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 R-1lLj5UIWoh for ; Wed, 25 Feb 2009 03:13:21 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id ED3513A6AA3 for ; Wed, 25 Feb 2009 03:13:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 57EC5A0439; Wed, 25 Feb 2009 03:13:42 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29568-08; Wed, 25 Feb 2009 03:13:42 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id B44CFA0438; Wed, 25 Feb 2009 03:13:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <107AAAF2-FA04-485F-AD82-091E69E27B64@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Wed, 25 Feb 2009 06:13:41 -0500 To: OSPF List X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: Sina Mirtorabi Subject: [OSPF] WG Last Call for Support of address families in OSPFv3 - draft-ietf-ospf-af-alt-07.txt 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, 25 Feb 2009 11:13:22 -0000 This starts the Working Group Last Call for the subject document. The target status is proposed standard. The WG Last Call will start today and end March 12th at 12:00 AM EDT. Thanks, Acee From dward@cisco.com Wed Feb 25 11:23:30 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 A16F228C2AC for ; Wed, 25 Feb 2009 11:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, J_CHICKENPOX_43=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 NRRkmZo1rciz for ; Wed, 25 Feb 2009 11:23:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 999B528C2A0 for ; Wed, 25 Feb 2009 11:23:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,266,1233532800"; d="scan'208";a="38395817" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2009 19:23:49 +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 n1PJNnwL014755; Wed, 25 Feb 2009 14:23:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1PJNkLV029091; Wed, 25 Feb 2009 19:23:49 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Feb 2009 14:23:48 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Feb 2009 14:23:47 -0500 Message-Id: <32168452-B8EF-46D6-AB48-16078E75B207@cisco.com> From: David Ward To: Acee Lindem In-Reply-To: <107AAAF2-FA04-485F-AD82-091E69E27B64@redback.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 13:23:45 -0600 References: <107AAAF2-FA04-485F-AD82-091E69E27B64@redback.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 25 Feb 2009 19:23:47.0417 (UTC) FILETIME=[94C1C490:01C9977E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1634; t=1235589829; x=1236453829; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[OSPF]=20WG=20Last=20Call=20for=20Suppo rt=20of=20address=20families=20in=20OSPFv3=20-=20draft-ietf- ospf-af-alt-07.txt |Sender:=20 |To:=20Acee=20Lindem=20; bh=wtH86YovVq+yI0C5EDUqsFIJ9k8bG3W5sSyaEK+rlXI=; b=P9s15GwabQNk+tVQV5naZgf12p02IVMNo7b0pMZmo3K5GHG1alebjk+4Mc cnJub3DVlVFcls4eugwEdFXk+khSsomccYh3df2K1RgK3+f5o6NrN/kweHej 9+T92wfm4E; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Sina Mirtorabi , OSPF List , Ross Callon Subject: Re: [OSPF] WG Last Call for Support of address families in OSPFv3 - draft-ietf-ospf-af-alt-07.txt 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, 25 Feb 2009 19:23:30 -0000 Acee and OSPF'ers - A few comments: 0) It's unclear what happens if the value of the instance_id (which has semantics of AF/SAF) and the prefix options bits in 2.2.2 don't match. What happens in this failure case and what should win? a) in addition, what happens if an instance_id >= 128 is received? 1) The draft may want to call out a few more details that are in 5340 that the instance_id is per link and a few of the rules in 5340. 2) It isn't clear if there are or should be rules for leaking routes between instances. For example: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-07.txt requires that leaking and policy is required. Given that, it seems you have to have some general rules and failure conditions. For example, leaking between instances of the same AF could be allowed and they are to be imported as ASE ... 3) Do you want to set aside a small set of instance_ids for non- routing information at this time? Given you have taken on the work, and you know it is coming maybe it makes sense now? I have other comments but, this is a start. -DWard On Feb 25, 2009, at 5:13 AM, Acee Lindem wrote: > This starts the Working Group Last Call for the subject document. > The target status is proposed standard. > The WG Last Call will start today and end March 12th at 12:00 AM EDT. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From prvs=30209b6c8=acee@redback.com Fri Feb 27 08:58: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 B81C928C122 for ; Fri, 27 Feb 2009 08:58:24 -0800 (PST) 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 uDnbqwqmdtHf for ; Fri, 27 Feb 2009 08:58:23 -0800 (PST) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id ACE2B3A6AFA for ; Fri, 27 Feb 2009 08:58:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,277,1233561600"; d="scan'208";a="45992" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 27 Feb 2009 08:58:46 -0800 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7DC58A30A29; Fri, 27 Feb 2009 08:58:46 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17288-05; Fri, 27 Feb 2009 08:58:46 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id B30CCA30A28; Fri, 27 Feb 2009 08:58:45 -0800 (PST) In-Reply-To: <00275A5B436CA441900CB10936742A3801C613B1@FRVELSMBS22.ad2.ad.alcatel.com> References: <00275A5B436CA441900CB10936742A3801C144DB@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A3801C613B1@FRVELSMBS22.ad2.ad.alcatel.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: Fri, 27 Feb 2009 11:58:44 -0500 To: PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance 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, 27 Feb 2009 17:00:48 -0000 Dimitri, See inline. On Feb 18, 2009, at 3:15 AM, PAPADIMITRIOU Dimitri wrote: > acee: > >> -----Original Message----- >> From: Acee Lindem [mailto:acee@redback.com] >> Sent: Tuesday, February 17, 2009 4:06 PM >> To: PAPADIMITRIOU Dimitri >> Cc: OSPF List >> Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance >> >> >> On Feb 15, 2009, at 5:18 AM, PAPADIMITRIOU Dimitri wrote: >> >>> >>> pls, re-read your meeting minutes. >>> >>> The first issue is: fixed segmentation of resources between >> instances >>> processing non-opaque and opaque LSAs is less robust than a flexible >>> sharing of these resources assuming events triggering opaque and >>> non-opaque LSAs (used indirectly by some application) are >> independent. >>> The assumption of correlation (opaque LSAs directly >> processed by OSPF) >>> is left possible by RFC 2740. Nevertheless, this draft does not >>> isolate >>> the "IP Routing instance" from the latter LSAs. >>> >>> The second issue is: i) the proposal moves from multiplexed >>> exchanges to >>> serialized exchanges of LS PDUs between peering instances of >>> opaques and >>> non-opaque LSAs, ii) the messaging between different instances still >>> share the same links and header processing (note: by definition >>> instances are "co-located") but are under the control of different >>> instances thus requiring further prioritization at the sender side. >>> Thus, the current proposal further constraints the sender's >>> instances to >>> expectedly prevent overloading the receiver. This is made >> possible by >>> putting down to the OSPF header (instead of the LSA header) the >>> information with which prioritization at the sender would >> be possible. >>> Nevertheless, is that not strictly equivalent to prioritize >> on the LSA >>> header when the instances are common i.e. the draft adds an >> identifier >>> because it puts processing down the OSPF header. The result is not >>> different from what would be possible using the "Opaque Type" (in >>> combination with the LS Type) since it is only for a sub-class of >>> Opaque >>> LSA (those that are not directly processed by OSPF) that >> the issue of >>> overloading expectedly arises. >> >> Section 2.4 addresses IP/IPv6 packet prioritization and many (if not >> most) commercial routers use the packet precedence for internal >> prioritization. What more would be required? We could state that the >> precedence MAY also used for internal prioritization. However, we >> want to steer clear of implying a specific implementation. > > The point here is that this notion of "instance ID" is not meant to > solve any "overload" problem it is primarily a separation of instances > for administrative and policy reasons. Any of them are instances > exchanges LSAs and Opaque LSAs. > > In the present case, the problem - that i perfectly acknowledge - is > resulting from the dual use of Opaque LSAs wrt other LSA exchanges > whereas the instance ID does not assume such separation. I believe the OSPF instance provide a natural boundary to address this problem better than mechanisms within a protocol. Refer to section 2.4. 2.4. Network Prioritization While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP precedence Internetwork Control, any packets sent by a transport instance will be sent with IP precedence Flash (B'011'). This is only appropriate given that this is a pretty flashy mechanism. Similarly, OSPFv3 transport instance packets will be sent with the traffic class mapped to flash (B'011') as specified in ([OSPFV3]. By setting the IP/IPv6 precedence differently for OSPF transport instance packets, normal OSPF routing instances can be given priority during both packet transmission and reception. In fact, Some router implemenations map the IP precedence directly to their internal packet priority. However, implementation issues are beyond the scope of this document. Thanks, Acee > > Thanks, > -dimitri. >> Thanks, >> Acee >> >> >>> >>> -d. >>> >>> >>>> -----Original Message----- >>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >>>> Behalf Of Acee Lindem >>>> Sent: Saturday, February 14, 2009 10:44 PM >>>> To: OSPF List >>>> Subject: [OSPF] OSPF Multi-Instance and Transport Instance >>>> >>>> In Minneapolis, there was some interest in making these WG group >>>> documents. Additionally, the AD have sponsored this activity given >>>> that a solution is being actively pursued in the ISIS WG (though >>>> significantly less powerful). >>>> >>>> There was one dissenting comment that one could achieve the same >>>> results with a single instance given sufficient invention (aka, the >>>> "even pigs can fly" argument). I've added text to the transport >>>> instance draft as well as mechanisms and text enabling sparse >>>> topologies that I believe clearly demonstrates the superiority of >>>> this solution. Hence, I like to now ask if there is any further >>>> reason not to make these WG documents? >>>> >>>> Here are the current versions: >>>> >>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-multi- >>>> instance-02.txt >>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-transport- >>>> instance-02.txt >>>> >>>> Thanks, >>>> Acee >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >> >> From prvs=30209b6c8=acee@redback.com Fri Feb 27 09:49: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 31FFE28C34D for ; Fri, 27 Feb 2009 09:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 hx7Tte3iyLE2 for ; Fri, 27 Feb 2009 09:49:22 -0800 (PST) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id C7F2628C365 for ; Fri, 27 Feb 2009 09:49:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,277,1233561600"; d="scan'208,217";a="47183" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 27 Feb 2009 09:49:44 -0800 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B613AE3768 for ; Fri, 27 Feb 2009 09:49:44 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04822-07 for ; Fri, 27 Feb 2009 09:49:44 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id AE24AE3766 for ; Fri, 27 Feb 2009 09:49:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753.1) To: OSPF List Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-47--248255052 References: From: Acee Lindem Date: Fri, 27 Feb 2009 12:49:42 -0500 X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] Fwd: OSPF Multi-Instance and Transport Instance 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, 27 Feb 2009 17:49:24 -0000 --Apple-Mail-47--248255052 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I believe we are now ready to take this AD sponsored work on and make these OSPF WG documents. Thanks, Acee Begin forwarded message: > From: Acee Lindem > Date: February 27, 2009 11:58:44 AM EST > To: PAPADIMITRIOU Dimitri > Cc: OSPF List > Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance > > Dimitri, > See inline. > On Feb 18, 2009, at 3:15 AM, PAPADIMITRIOU Dimitri wrote: > >> acee: >> >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee@redback.com] >>> Sent: Tuesday, February 17, 2009 4:06 PM >>> To: PAPADIMITRIOU Dimitri >>> Cc: OSPF List >>> Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance >>> >>> >>> On Feb 15, 2009, at 5:18 AM, PAPADIMITRIOU Dimitri wrote: >>> >>>> >>>> pls, re-read your meeting minutes. >>>> >>>> The first issue is: fixed segmentation of resources between >>> instances >>>> processing non-opaque and opaque LSAs is less robust than a >>>> flexible >>>> sharing of these resources assuming events triggering opaque and >>>> non-opaque LSAs (used indirectly by some application) are >>> independent. >>>> The assumption of correlation (opaque LSAs directly >>> processed by OSPF) >>>> is left possible by RFC 2740. Nevertheless, this draft does not >>>> isolate >>>> the "IP Routing instance" from the latter LSAs. >>>> >>>> The second issue is: i) the proposal moves from multiplexed >>>> exchanges to >>>> serialized exchanges of LS PDUs between peering instances of >>>> opaques and >>>> non-opaque LSAs, ii) the messaging between different instances >>>> still >>>> share the same links and header processing (note: by definition >>>> instances are "co-located") but are under the control of different >>>> instances thus requiring further prioritization at the sender side. >>>> Thus, the current proposal further constraints the sender's >>>> instances to >>>> expectedly prevent overloading the receiver. This is made >>> possible by >>>> putting down to the OSPF header (instead of the LSA header) the >>>> information with which prioritization at the sender would >>> be possible. >>>> Nevertheless, is that not strictly equivalent to prioritize >>> on the LSA >>>> header when the instances are common i.e. the draft adds an >>> identifier >>>> because it puts processing down the OSPF header. The result is not >>>> different from what would be possible using the "Opaque Type" (in >>>> combination with the LS Type) since it is only for a sub-class of >>>> Opaque >>>> LSA (those that are not directly processed by OSPF) that >>> the issue of >>>> overloading expectedly arises. >>> >>> Section 2.4 addresses IP/IPv6 packet prioritization and many (if not >>> most) commercial routers use the packet precedence for internal >>> prioritization. What more would be required? We could state that the >>> precedence MAY also used for internal prioritization. However, we >>> want to steer clear of implying a specific implementation. >> >> The point here is that this notion of "instance ID" is not meant to >> solve any "overload" problem it is primarily a separation of >> instances >> for administrative and policy reasons. Any of them are instances >> exchanges LSAs and Opaque LSAs. >> >> In the present case, the problem - that i perfectly acknowledge - is >> resulting from the dual use of Opaque LSAs wrt other LSA exchanges >> whereas the instance ID does not assume such separation. > > I believe the OSPF instance provide a natural boundary to address this > problem better than mechanisms within a protocol. Refer to section > 2.4. > > 2.4. Network Prioritization > > While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP > precedence Internetwork Control, any packets sent by a transport > instance will be sent with IP precedence Flash (B'011'). This is > only appropriate given that this is a pretty flashy mechanism. > > Similarly, OSPFv3 transport instance packets will be sent with the > traffic class mapped to flash (B'011') as specified in ([OSPFV3]. > > By setting the IP/IPv6 precedence differently for OSPF transport > instance packets, normal OSPF routing instances can be given > priority > during both packet transmission and reception. In fact, Some > router > implemenations map the IP precedence directly to their internal > packet priority. However, implementation issues are beyond the > scope > of this document. > > Thanks, > Acee > > > >> >> Thanks, >> -dimitri. >>> Thanks, >>> Acee >>> >>> >>>> >>>> -d. >>>> >>>> >>>>> -----Original Message----- >>>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >>>>> Behalf Of Acee Lindem >>>>> Sent: Saturday, February 14, 2009 10:44 PM >>>>> To: OSPF List >>>>> Subject: [OSPF] OSPF Multi-Instance and Transport Instance >>>>> >>>>> In Minneapolis, there was some interest in making these WG group >>>>> documents. Additionally, the AD have sponsored this activity given >>>>> that a solution is being actively pursued in the ISIS WG (though >>>>> significantly less powerful). >>>>> >>>>> There was one dissenting comment that one could achieve the same >>>>> results with a single instance given sufficient invention (aka, >>>>> the >>>>> "even pigs can fly" argument). I've added text to the transport >>>>> instance draft as well as mechanisms and text enabling sparse >>>>> topologies that I believe clearly demonstrates the superiority of >>>>> this solution. Hence, I like to now ask if there is any further >>>>> reason not to make these WG documents? >>>>> >>>>> Here are the current versions: >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-multi- >>>>> instance-02.txt >>>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-transport- >>>>> instance-02.txt >>>>> >>>>> Thanks, >>>>> Acee >>>>> _______________________________________________ >>>>> 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 --Apple-Mail-47--248255052 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I believe we are now ready to = take this AD sponsored work on and make these OSPF WG = documents.=A0
Thanks,
Acee=A0

Begin = forwarded message:

From: = Acee Lindem <acee@redback.com>
Date: = February 27, 2009 11:58:44 AM EST
To: PAPADIMITRIOU Dimitri <Dimitri.Papadimitr= iou@alcatel-lucent.be>
Cc: OSPF List <ospf@ietf.org>
Subject: = Re: [OSPF] OSPF Multi-Instance and Transport = Instance
Dimitri,
See inline.
On Feb 18, = 2009, at 3:15 AM, PAPADIMITRIOU Dimitri wrote:

acee:

-----Original = Message-----
From: Acee Lindem [mailto:acee@redback.com]
Sent: Tuesday, February 17, 2009 4:06 PM
To: PAPADIMITRIOU Dimitri
Cc: OSPF List
Subject: Re: = [OSPF] OSPF Multi-Instance and Transport Instance


On Feb 15, = 2009, at 5:18 AM, PAPADIMITRIOU Dimitri wrote:


pls, re-read your meeting minutes.

The = first issue is: fixed segmentation of resources between
=
instances
processing non-opaque and opaque = LSAs is less robust than a flexible
sharing of = these resources assuming events triggering opaque and
non-opaque LSAs (used indirectly by some = application) are
The = assumption of correlation (opaque LSAs directly
processed by OSPF)
is left possible by RFC 2740. = Nevertheless, this draft does not
the "IP Routing instance" from = the latter LSAs.

The second issue is: i) the proposal moves from = multiplexed
exchanges to
serialized exchanges of LS PDUs between peering = instances of
opaques and
non-opaque LSAs, ii) the messaging between different = instances still
share the same links and header = processing (note: by definition
instances are = "co-located") but are under the control of different
instances thus requiring further prioritization at = the sender side.
Thus, the current proposal = further constraints the sender's
instances = to
expectedly prevent overloading the receiver. = This is made
possible = by
putting down = to the OSPF header (instead of the LSA header) the
information with which prioritization at the sender = would
be possible.
=
Nevertheless, is that not = strictly equivalent to prioritize
on the LSA
header when the instances are common i.e. the draft = adds an
identifier
=
because it puts processing = down the OSPF header. The result is not
combination with the LS Type) = since it is only for a sub-class of
LSA (those that are not directly = processed by OSPF) that
the = issue of
overloading = expectedly arises.

Section 2.4 addresses IP/IPv6 = packet prioritization and many (if not
most) = commercial routers use the packet precedence for internal
prioritization. What more would be required? We = could state that the
precedence MAY also used = for internal prioritization. However, we
want to = steer clear of implying a specific implementation.
=

The point here is that this notion of "instance ID" = is not meant to
solve any "overload" problem it = is primarily a separation of instances
for = administrative and policy reasons. Any of them are instances
exchanges LSAs and Opaque LSAs.

In the = present case, the problem - that i perfectly acknowledge - is
resulting from the dual use of Opaque LSAs wrt other = LSA exchanges
whereas the instance ID does not = assume such separation.

I believe the = OSPF instance provide a natural boundary to address this
problem better than mechanisms within a protocol. = Refer to section 2.4.
2.4.=A0 Network = Prioritization

=A0=A0 = While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with = IP
=A0=A0 = precedence Internetwork Control, any packets sent by a = transport
=A0=A0 instance will be sent with = IP precedence Flash (B'011').=A0 = This is
=A0=A0 only appropriate given = that this is a pretty flashy mechanism.

=A0=A0 Similarly, OSPFv3 = transport instance packets will be sent with the
=A0=A0 = traffic class mapped to flash (B'011') as specified in = ([OSPFV3].

=A0=A0 = By setting the IP/IPv6 precedence differently for OSPF = transport
=A0=A0 instance packets, normal = OSPF routing instances can be given priority
=A0=A0 = during both packet transmission and reception.=A0 In fact, Some = router
=A0=A0 implemenations map the IP = precedence directly to their internal
=A0=A0 packet priority.=A0 However, implementation = issues are beyond the scope
=A0=A0 of this = document.

Thanks,




-dimitri.
Thanks,
Acee


=
-d.


From: = ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] = On
Behalf Of Acee Lindem
Sent: Saturday, February 14, 2009 10:44 PM
To: OSPF List
Subject: = [OSPF] OSPF Multi-Instance and Transport Instance

In = Minneapolis, there was some interest in making these WG group
documents. Additionally, the AD have sponsored this = activity given
that a solution is being = actively pursued in the ISIS WG (though

There was one dissenting comment = that one could achieve the same
results with = a single instance given sufficient invention (aka, the
"even pigs can fly" argument). I've added text to = the transport
instance draft as well as = mechanisms and text enabling sparse
topologies = that I believe clearly demonstrates the superiority of
this solution. Hence, I like to now ask if there is = any further
reason not to make these WG = documents?

Here are the current versions:

instance-02.txt
instance-02.txt

Thanks,
Acee
OSPF mailing list




OSPF mailing list
=

= --Apple-Mail-47--248255052-- From rcallon@juniper.net Fri Feb 27 10:45: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 7684F28C391 for ; Fri, 27 Feb 2009 10:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 HYC0qBIRPWv4 for ; Fri, 27 Feb 2009 10:45:43 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 8FBBA3A6A7B for ; Fri, 27 Feb 2009 10:45:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSag07uACVi2spTdi8X//0sEDsZ9eoR4Y@postini.com; Fri, 27 Feb 2009 10:46:06 PST 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.340.0; Fri, 27 Feb 2009 10:45:39 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 10:45:39 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 10:45:39 -0800 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, 27 Feb 2009 13:45:36 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05CA1383@emailwf1.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-ccamp-gmpls-ason-routing-ospf (OSPFv2 Routing Protocols Extensions for ASON Routing) to Experimental RFC Thread-Index: AcmY/00MLZY9mqsdSk+WJJMto3QAJgAC4qjg From: Ross Callon To: X-OriginalArrivalTime: 27 Feb 2009 18:45:39.0209 (UTC) FILETIME=[95B46F90:01C9990B] Subject: [OSPF] FW: Last Call: draft-ietf-ccamp-gmpls-ason-routing-ospf (OSPFv2 Routing Protocols Extensions for ASON Routing) to Experimental RFC 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, 27 Feb 2009 18:45:44 -0000 FYI. This document is potentially of interest to OSPF folks, therefore please note that it is currently in IETF last call. Thanks, Ross -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: 27 February 2009 12:17 To: IETF-Announce Cc: ccamp@ops.ietf.org Subject: Last Call: draft-ietf-ccamp-gmpls-ason-routing-ospf (OSPFv2 Routing Protocols Extensions for ASON Routing) to Experimental RFC=20 The IESG has received a request from the Common Control and Measurement=20 Plane WG (ccamp) to consider the following document: - 'OSPFv2 Routing Protocols Extensions for ASON Routing ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-13. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing- ospf-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 15037&rfc_flag=3D0 The following IPR Declarations may be related to this I-D: _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From Dimitri.Papadimitriou@alcatel-lucent.be Fri Feb 27 10:49: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 911033A6A7B for ; Fri, 27 Feb 2009 10:49:17 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 YDZGdoHitAsC for ; Fri, 27 Feb 2009 10:49:16 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 135C93A683E for ; Fri, 27 Feb 2009 10:49:15 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1RInaCn031526; Fri, 27 Feb 2009 19:49:36 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Feb 2009 19:49:35 +0100 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, 27 Feb 2009 19:48:46 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801D46CC5@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Fwd: OSPF Multi-Instance and Transport Instance Thread-Index: AcmZBBCY5CV9cdIwQMCTOwrOl/sUHQABomaA References: From: "PAPADIMITRIOU Dimitri" To: "Acee Lindem" , "OSPF List" X-OriginalArrivalTime: 27 Feb 2009 18:49:35.0983 (UTC) FILETIME=[22D547F0:01C9990C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [OSPF] Fwd: OSPF Multi-Instance and Transport Instance 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, 27 Feb 2009 18:49:17 -0000 acee,=20 since so far, I have seen two people discussing on this list on this specific thread. i would have hoped much more debates before concluding on the (bottomline) approach to follow. thanks,=20 -d.=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Acee Lindem > Sent: Friday, February 27, 2009 6:50 PM > To: OSPF List > Subject: [OSPF] Fwd: OSPF Multi-Instance and Transport Instance >=20 > I believe we are now ready to take this AD sponsored work on=20 > and make these OSPF WG documents.=20 > Thanks, > Acee=20 >=20 >=20 > Begin forwarded message: >=20 >=20 > From: Acee Lindem > Date: February 27, 2009 11:58:44 AM EST > To: PAPADIMITRIOU Dimitri=20 > > Cc: OSPF List > Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance >=20 > Dimitri, > See inline. > On Feb 18, 2009, at 3:15 AM, PAPADIMITRIOU Dimitri wrote: >=20 >=20 > acee: >=20 >=20 > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com] > Sent: Tuesday, February 17, 2009 4:06 PM > To: PAPADIMITRIOU Dimitri > Cc: OSPF List > Subject: Re: [OSPF] OSPF Multi-Instance=20 > and Transport Instance >=20 >=20 > On Feb 15, 2009, at 5:18 AM,=20 > PAPADIMITRIOU Dimitri wrote: >=20 >=20 >=20 > pls, re-read your meeting minutes. >=20 > The first issue is: fixed=20 > segmentation of resources between >=20 > instances >=20 > processing non-opaque and=20 > opaque LSAs is less robust than a flexible > sharing of these resources=20 > assuming events triggering opaque and > non-opaque LSAs (used=20 > indirectly by some application) are >=20 > independent. >=20 > The assumption of correlation=20 > (opaque LSAs directly >=20 > processed by OSPF) >=20 > is left possible by RFC 2740.=20 > Nevertheless, this draft does not > isolate > the "IP Routing instance" from=20 > the latter LSAs. >=20 > The second issue is: i) the=20 > proposal moves from multiplexed > exchanges to > serialized exchanges of LS PDUs=20 > between peering instances of > opaques and > non-opaque LSAs, ii) the=20 > messaging between different instances still > share the same links and header=20 > processing (note: by definition > instances are "co-located") but=20 > are under the control of different > instances thus requiring=20 > further prioritization at the sender side. > Thus, the current proposal=20 > further constraints the sender's > instances to > expectedly prevent overloading=20 > the receiver. This is made >=20 > possible by >=20 > putting down to the OSPF header=20 > (instead of the LSA header) the > information with which=20 > prioritization at the sender would >=20 > be possible. >=20 > Nevertheless, is that not=20 > strictly equivalent to prioritize >=20 > on the LSA >=20 > header when the instances are=20 > common i.e. the draft adds an >=20 > identifier >=20 > because it puts processing down=20 > the OSPF header. The result is not > different from what would be=20 > possible using the "Opaque Type" (in > combination with the LS Type)=20 > since it is only for a sub-class of > Opaque > LSA (those that are not=20 > directly processed by OSPF) that >=20 > the issue of >=20 > overloading expectedly arises. >=20 >=20 > Section 2.4 addresses IP/IPv6 packet=20 > prioritization and many (if not > most) commercial routers use the packet=20 > precedence for internal > prioritization. What more would be=20 > required? We could state that the > precedence MAY also used for internal=20 > prioritization. However, we > want to steer clear of implying a=20 > specific implementation. >=20 >=20 > The point here is that this notion of "instance=20 > ID" is not meant to > solve any "overload" problem it is primarily a=20 > separation of instances > for administrative and policy reasons. Any of=20 > them are instances > exchanges LSAs and Opaque LSAs. >=20 > In the present case, the problem - that i=20 > perfectly acknowledge - is > resulting from the dual use of Opaque LSAs wrt=20 > other LSA exchanges > whereas the instance ID does not assume such separation. >=20 >=20 > I believe the OSPF instance provide a natural boundary=20 > to address this > problem better than mechanisms within a protocol. Refer=20 > to section 2.4. >=20 > 2.4. Network Prioritization >=20 > While OSPFv2 (section 4.3 in [OSPFV2]) are normally=20 > sent with IP > precedence Internetwork Control, any packets sent by=20 > a transport > instance will be sent with IP precedence Flash=20 > (B'011'). This is > only appropriate given that this is a pretty flashy=20 > mechanism. >=20 > Similarly, OSPFv3 transport instance packets will be=20 > sent with the > traffic class mapped to flash (B'011') as specified=20 > in ([OSPFV3]. >=20 > By setting the IP/IPv6 precedence differently for=20 > OSPF transport > instance packets, normal OSPF routing instances can=20 > be given priority > during both packet transmission and reception. In=20 > fact, Some router > implemenations map the IP precedence directly to=20 > their internal > packet priority. However, implementation issues are=20 > beyond the scope > of this document. >=20 > Thanks, > Acee >=20 >=20 >=20 >=20 >=20 > Thanks, > -dimitri. >=20 > Thanks, > Acee >=20 >=20 >=20 >=20 > -d. >=20 >=20 >=20 > -----Original Message----- > From:=20 > ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > Behalf Of Acee Lindem > Sent: Saturday,=20 > February 14, 2009 10:44 PM > To: OSPF List > Subject: [OSPF] OSPF=20 > Multi-Instance and Transport Instance >=20 > In Minneapolis, there=20 > was some interest in making these WG group > documents.=20 > Additionally, the AD have sponsored this activity given > that a solution is=20 > being actively pursued in the ISIS WG (though > significantly less powerful). >=20 > There was one=20 > dissenting comment that one could achieve the same > results with a single=20 > instance given sufficient invention (aka, the > "even pigs can fly"=20 > argument). I've added text to the transport > instance draft as well=20 > as mechanisms and text enabling sparse > topologies that I=20 > believe clearly demonstrates the superiority of > this solution. Hence, I=20 > like to now ask if there is any further > reason not to make=20 > these WG documents? >=20 > Here are the current versions: >=20 > =09 > http://www.ietf.org/internet-drafts/draft-acee-ospf-multi- > instance-02.txt > =09 > http://www.ietf.org/internet-drafts/draft-acee-ospf-transport- > instance-02.txt >=20 > Thanks, > Acee > =09 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > =09 > https://www.ietf.org/mailman/listinfo/ospf >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 >=20 >=20 From prvs=30209b6c8=acee@redback.com Fri Feb 27 11:05: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 34E8228C175 for ; Fri, 27 Feb 2009 11:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 GZ53oZ8Qhqv2 for ; Fri, 27 Feb 2009 11:05:15 -0800 (PST) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id BDBE73A6B02 for ; Fri, 27 Feb 2009 11:05:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,277,1233561600"; d="scan'208";a="49035" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 27 Feb 2009 11:05:38 -0800 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8C575D5DD8D; Fri, 27 Feb 2009 11:05:38 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00362-06; Fri, 27 Feb 2009 11:05:38 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id D4F4CD5DD8C; Fri, 27 Feb 2009 11:05:37 -0800 (PST) In-Reply-To: <00275A5B436CA441900CB10936742A3801D46CC5@FRVELSMBS22.ad2.ad.alcatel.com> References: <00275A5B436CA441900CB10936742A3801D46CC5@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <99055F48-A848-4A36-BED9-EDCE2054C79F@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Fri, 27 Feb 2009 14:05:36 -0500 To: "PAPADIMITRIOU Dimitri" X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] Fwd: OSPF Multi-Instance and Transport Instance 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, 27 Feb 2009 19:05:18 -0000 I'd agree if it hadn't been discussed at the last two IETFs with moderate support and virtually no opposition. Thanks, Acee On Feb 27, 2009, at 1:48 PM, PAPADIMITRIOU Dimitri wrote: > acee, > > since so far, I have seen two people discussing on this list on this > specific thread. i would have hoped much more debates before > concluding > on the (bottomline) approach to follow. > > thanks, > -d. > >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> Behalf Of Acee Lindem >> Sent: Friday, February 27, 2009 6:50 PM >> To: OSPF List >> Subject: [OSPF] Fwd: OSPF Multi-Instance and Transport Instance >> >> I believe we are now ready to take this AD sponsored work on >> and make these OSPF WG documents. >> Thanks, >> Acee >> >> >> Begin forwarded message: >> >> >> From: Acee Lindem >> Date: February 27, 2009 11:58:44 AM EST >> To: PAPADIMITRIOU Dimitri >> >> Cc: OSPF List >> Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance >> >> Dimitri, >> See inline. >> On Feb 18, 2009, at 3:15 AM, PAPADIMITRIOU Dimitri wrote: >> >> >> acee: >> >> >> -----Original Message----- >> From: Acee Lindem [mailto:acee@redback.com] >> Sent: Tuesday, February 17, 2009 4:06 PM >> To: PAPADIMITRIOU Dimitri >> Cc: OSPF List >> Subject: Re: [OSPF] OSPF Multi-Instance >> and Transport Instance >> >> >> On Feb 15, 2009, at 5:18 AM, >> PAPADIMITRIOU Dimitri wrote: >> >> >> >> pls, re-read your meeting minutes. >> >> The first issue is: fixed >> segmentation of resources between >> >> instances >> >> processing non-opaque and >> opaque LSAs is less robust than a flexible >> sharing of these resources >> assuming events triggering opaque and >> non-opaque LSAs (used >> indirectly by some application) are >> >> independent. >> >> The assumption of correlation >> (opaque LSAs directly >> >> processed by OSPF) >> >> is left possible by RFC 2740. >> Nevertheless, this draft does not >> isolate >> the "IP Routing instance" from >> the latter LSAs. >> >> The second issue is: i) the >> proposal moves from multiplexed >> exchanges to >> serialized exchanges of LS PDUs >> between peering instances of >> opaques and >> non-opaque LSAs, ii) the >> messaging between different instances still >> share the same links and header >> processing (note: by definition >> instances are "co-located") but >> are under the control of different >> instances thus requiring >> further prioritization at the sender side. >> Thus, the current proposal >> further constraints the sender's >> instances to >> expectedly prevent overloading >> the receiver. This is made >> >> possible by >> >> putting down to the OSPF header >> (instead of the LSA header) the >> information with which >> prioritization at the sender would >> >> be possible. >> >> Nevertheless, is that not >> strictly equivalent to prioritize >> >> on the LSA >> >> header when the instances are >> common i.e. the draft adds an >> >> identifier >> >> because it puts processing down >> the OSPF header. The result is not >> different from what would be >> possible using the "Opaque Type" (in >> combination with the LS Type) >> since it is only for a sub-class of >> Opaque >> LSA (those that are not >> directly processed by OSPF) that >> >> the issue of >> >> overloading expectedly arises. >> >> >> Section 2.4 addresses IP/IPv6 packet >> prioritization and many (if not >> most) commercial routers use the packet >> precedence for internal >> prioritization. What more would be >> required? We could state that the >> precedence MAY also used for internal >> prioritization. However, we >> want to steer clear of implying a >> specific implementation. >> >> >> The point here is that this notion of "instance >> ID" is not meant to >> solve any "overload" problem it is primarily a >> separation of instances >> for administrative and policy reasons. Any of >> them are instances >> exchanges LSAs and Opaque LSAs. >> >> In the present case, the problem - that i >> perfectly acknowledge - is >> resulting from the dual use of Opaque LSAs wrt >> other LSA exchanges >> whereas the instance ID does not assume such separation. >> >> >> I believe the OSPF instance provide a natural boundary >> to address this >> problem better than mechanisms within a protocol. Refer >> to section 2.4. >> >> 2.4. Network Prioritization >> >> While OSPFv2 (section 4.3 in [OSPFV2]) are normally >> sent with IP >> precedence Internetwork Control, any packets sent by >> a transport >> instance will be sent with IP precedence Flash >> (B'011'). This is >> only appropriate given that this is a pretty flashy >> mechanism. >> >> Similarly, OSPFv3 transport instance packets will be >> sent with the >> traffic class mapped to flash (B'011') as specified >> in ([OSPFV3]. >> >> By setting the IP/IPv6 precedence differently for >> OSPF transport >> instance packets, normal OSPF routing instances can >> be given priority >> during both packet transmission and reception. In >> fact, Some router >> implemenations map the IP precedence directly to >> their internal >> packet priority. However, implementation issues are >> beyond the scope >> of this document. >> >> Thanks, >> Acee >> >> >> >> >> >> Thanks, >> -dimitri. >> >> Thanks, >> Acee >> >> >> >> >> -d. >> >> >> >> -----Original Message----- >> From: >> ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> Behalf Of Acee Lindem >> Sent: Saturday, >> February 14, 2009 10:44 PM >> To: OSPF List >> Subject: [OSPF] OSPF >> Multi-Instance and Transport Instance >> >> In Minneapolis, there >> was some interest in making these WG group >> documents. >> Additionally, the AD have sponsored this activity given >> that a solution is >> being actively pursued in the ISIS WG (though >> significantly less powerful). >> >> There was one >> dissenting comment that one could achieve the same >> results with a single >> instance given sufficient invention (aka, the >> "even pigs can fly" >> argument). I've added text to the transport >> instance draft as well >> as mechanisms and text enabling sparse >> topologies that I >> believe clearly demonstrates the superiority of >> this solution. Hence, I >> like to now ask if there is any further >> reason not to make >> these WG documents? >> >> Here are the current versions: >> >> >> http://www.ietf.org/internet-drafts/draft-acee-ospf-multi- >> instance-02.txt >> >> http://www.ietf.org/internet-drafts/draft-acee-ospf-transport- >> instance-02.txt >> >> Thanks, >> Acee >> >> _______________________________________________ >> 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 dward@cisco.com Fri Feb 27 12:43:45 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 6AE4A3A657C for ; Fri, 27 Feb 2009 12:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 gBwdJOKUEoHS for ; Fri, 27 Feb 2009 12:43:44 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 065743A6832 for ; Fri, 27 Feb 2009 12:43:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,278,1233532800"; d="scan'208";a="38739081" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2009 20:44:06 +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 n1RKi5HJ019333; Fri, 27 Feb 2009 15:44:05 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1RKi5uV021902; Fri, 27 Feb 2009 20:44:05 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 15:44:05 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 15:44:05 -0500 Message-Id: <159A4DF0-A07B-4AB5-9221-AED32B43593B@cisco.com> From: David Ward To: Acee Lindem 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 v930.3) Date: Fri, 27 Feb 2009 14:44:04 -0600 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 27 Feb 2009 20:44:05.0505 (UTC) FILETIME=[21632710:01C9991C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1224; t=1235767446; x=1236631446; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[OSPF]=20OSPF=20Multi-Instance=20and=20 Transport=20Instance |Sender:=20 |To:=20Acee=20Lindem=20; bh=lPKZNC4kAwYd/jgrCTmkj2VmgvbSmK1rlp5GNwCqzqg=; b=Inoi3QPFHq7wq672+ZSXsTxyA8rUnaXDuI4bUYaJL6X8lmuXtIIPApD85Y JKVOQ1SZyOLhXjl6+btVn4/J/F+CgroEnrGQXprRVwgf4kW1ylrDgvZYs2iX qCDW9Vrb7B; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: OSPF List Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance 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, 27 Feb 2009 20:43:45 -0000 I support this effort (and hope that OSPF catches up with the innovation and features in IS-IS.) -DWard On Feb 14, 2009, at 3:43 PM, Acee Lindem wrote: > In Minneapolis, there was some interest in making these WG group > documents. Additionally, the AD have sponsored this activity given > that a solution is being actively pursued in the ISIS WG (though > significantly less powerful). > > There was one dissenting comment that one could achieve the same > results with a single instance given sufficient invention (aka, the > "even pigs can fly" argument). I've added text to the transport > instance draft as well as mechanisms and text enabling sparse > topologies that I believe clearly demonstrates the superiority of > this solution. Hence, I like to now ask if there is any further > reason not to make these WG documents? > > Here are the current versions: > > http://www.ietf.org/internet-drafts/draft-acee-ospf-multi-instance-02.txt > http://www.ietf.org/internet-drafts/draft-acee-ospf-transport-instance-02.txt > > Thanks, > Acee_______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From Jonathan.Sadler@tellabs.com Fri Feb 27 12:56: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 668AC3A6849 for ; Fri, 27 Feb 2009 12:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 R0Snu+ZhwVpP for ; Fri, 27 Feb 2009 12:56:01 -0800 (PST) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 80D7F3A67B6 for ; Fri, 27 Feb 2009 12:56:01 -0800 (PST) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.38,278,1233532800"; d="scan'208";a="1277203497" Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4-priv.tellabs.com with ESMTP; 27 Feb 2009 20:56:23 +0000 Received: from usnvwwasdve2k7b.tellabs-west.tellabsinc.net ([172.23.195.46]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 14:56:23 -0600 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwasdve2k7b.tellabs-west.tellabsinc.net ([172.23.195.46]) with mapi; Fri, 27 Feb 2009 14:56:18 -0600 From: "Sadler, Jonathan B." To: David Ward , Acee Lindem Date: Fri, 27 Feb 2009 14:56:21 -0600 Thread-Topic: [OSPF] OSPF Multi-Instance and Transport Instance Thread-Index: AcmZHC4xmT5G90KkRwu+k1m7SILvlwAAXnow Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B260DCE8530@EX-NAP.tellabs-west.tellabsinc.net> References: <159A4DF0-A07B-4AB5-9221-AED32B43593B@cisco.com> In-Reply-To: <159A4DF0-A07B-4AB5-9221-AED32B43593B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2009 20:56:23.0233 (UTC) FILETIME=[D91B8310:01C9991D] Content-Transfer-Encoding: quoted-printable Cc: OSPF List Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance 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, 27 Feb 2009 20:56:02 -0000 I also support this concept and the related work on a mechanism. As for th= e specifics of the mechanism, I'll leave it to more brilliant OSPF'ers. Jonathan Sadler -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Dav= id Ward Sent: Friday, February 27, 2009 2:44 PM To: Acee Lindem Cc: OSPF List Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance I support this effort (and hope that OSPF catches up with the =20 innovation and features in IS-IS.) -DWard On Feb 14, 2009, at 3:43 PM, Acee Lindem wrote: > In Minneapolis, there was some interest in making these WG group =20 > documents. Additionally, the AD have sponsored this activity given =20 > that a solution is being actively pursued in the ISIS WG (though =20 > significantly less powerful). > > There was one dissenting comment that one could achieve the same =20 > results with a single instance given sufficient invention (aka, the =20 > "even pigs can fly" argument). I've added text to the transport =20 > instance draft as well as mechanisms and text enabling sparse =20 > topologies that I believe clearly demonstrates the superiority of =20 > this solution. Hence, I like to now ask if there is any further =20 > reason not to make these WG documents? > > Here are the current versions: > > http://www.ietf.org/internet-drafts/draft-acee-ospf-multi-instance-02.txt > http://www.ietf.org/internet-drafts/draft-acee-ospf-transport-instance-02= .txt > > Thanks, > Acee_______________________________________________ > 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From ppsenak@cisco.com Sat Feb 28 12:18:43 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 61FA93A6B4D for ; Sat, 28 Feb 2009 12:18:43 -0800 (PST) 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 RYVmv7K2a4DI for ; Sat, 28 Feb 2009 12:18:42 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 9D92E3A6B41 for ; Sat, 28 Feb 2009 12:18:41 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1SKJ4k29573; Sat, 28 Feb 2009 21:19:04 +0100 (CET) Received: from Cendo.local (dhcp-10-61-96-227.cisco.com [10.61.96.227]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1SKJ2t08109; Sat, 28 Feb 2009 21:19:02 +0100 (CET) Message-ID: <49A99C36.1000908@cisco.com> Date: Sat, 28 Feb 2009 21:19:02 +0100 From: Peter Psenak User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Abhijit Chaudhary References: <000e01c991e0$a3742710$4217120a@china.huawei.com> In-Reply-To: <000e01c991e0$a3742710$4217120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] Multi-topology OSPF, RFC : 4915 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, 28 Feb 2009 20:18:43 -0000 Abhijit, In section 4.3: A link may cease participating in the default topology if DefaultExclusionCapability is set to enabled. In this state, a router will only form adjacency with routers that set the MT-bit in their Hello packets. This will ensure that all routers have DefaultExclusionCapability enabled before the default topology can be disabled on a link. thanks, Peter Abhijit Chaudhary wrote: > I have a question Regarding Section 5 of OSPF-MT > > < RFC SNIPPET> > 5. Interoperability between MT-Capable and Non-MT-Capable Routers > The default metric field is mandatory in all LSAs (even when the > metric value is 0). Even when a link or prefix does not exist in the > default topology, a non-MT router will consider the zero value in the > metric field as a valid metric and consider the link or prefix as > part of the default topology. > > In order to prevent the above problem, an MT-capable router will > include all links as part of the default topology. If links need to > be removed from the default topology, an MT-capable router must be > configured in DefaultExclusionCapability mode. In this mode, routers > will ensure that all other routers in the area are in the > DefaultExclusionCapability mode before considering the MT-ID#0 metric > in the SPF calculation. Only then can the TOS 0 metric field in > Router-LSAs be safely ignored during the default topology SPF > computation. > > > > Now, how does an MT-capable router automatically ensure that all other > routers in the same area are also in DefaultExclusionCapability mode? > If I understand correctly, one solution can be for the calculating > router to ensure that the router-LSAs from all other routers in the area > have the MT Option set. But then, it is not mandatory that router-LSAs > MUST have MT-bit set. > > Is there any other solution? > > Thanks, > - Abhijit > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf