From molbio@agate.plala.or.jp Thu Jan 1 22:09:21 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295C43A6AEB for ; Thu, 1 Jan 2009 22:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.118 X-Spam-Level: X-Spam-Status: No, score=-74.118 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 4d68qhTUm3tL for ; Thu, 1 Jan 2009 22:09:20 -0800 (PST) Received: from ppp91-77-44-33.pppoe.mtu-net.ru (ppp91-77-44-33.pppoe.mtu-net.ru [91.77.44.33]) by core3.amsl.com (Postfix) with SMTP id 580783A6AE9 for ; Thu, 1 Jan 2009 22:09:18 -0800 (PST) To: Subject: Come upstairs! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090102060919.580783A6AE9@core3.amsl.com> Date: Thu, 1 Jan 2009 22:09:18 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From 306423.311704@vux.bos.netsolhost.com Fri Jan 2 02:10:09 2009 Return-Path: <306423.311704@vux.bos.netsolhost.com> X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68933A67FD for ; Fri, 2 Jan 2009 02:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_72=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 ku2dy0DpcSni for ; Fri, 2 Jan 2009 02:10:08 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id BF7003A6906 for ; Fri, 2 Jan 2009 02:10:06 -0800 (PST) Received: from vux.bos.netsolhost.com ([10.49.37.106]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id n02A9qNE001738 for ; Fri, 2 Jan 2009 05:09:54 -0500 Received: from vux61.mgt.hosting.dc2.netsol.com (smmsp@localhost [127.0.0.1]) by vux.bos.netsolhost.com (8.13.7/8.13.7) with ESMTP id n02A8gu1030666 for ; Fri, 2 Jan 2009 05:09:52 -0500 Received: (from 306423.311704@localhost) by vux61.mgt.hosting.dc2.netsol.com (8.13.7/8.13.7/Submit) id n02A7Jnr030011; Fri, 2 Jan 2009 05:07:19 -0500 Date: Fri, 2 Jan 2009 05:07:19 -0500 Message-Id: <200901021007.n02A7Jnr030011@vux61.mgt.hosting.dc2.netsol.com> To: ospf-archive@ietf.org Subject: Dear e-mail user. From: WEBMASTER PANEL Reply-To: webmasterpanel@msn.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Dear e-mail user, This message was sent automatically by Webmaster panel program which periodically checks the size of inbox, where new messages are received.The program is run weekly to ensure no one's inbox grows too large. If your inbox becomes too large, you will be unable to receive new email. Just before this message was sent, you had 18 Megabytes (MB) or more of messages stored in your inbox on mail. To help us re-set your SPACE on our database prior to maintain our INBOX, you must reply to this e-mail and enter your Current User name ( ) and Password ( ) You will continue to receive this warning message periodically if your inbox size continues to be between 18 and 20 MB. If your inbox size grows to 20 MB, then a program on mail will move your oldest email to a folder in your home directory to ensure that you will continue to be able to receive incoming email. You will be notified by email that this has taken place. If your inbox grows to 25 MB, you will be unable to receive new email as it will be returned to the sender. After you read a message,it is best to REPLY and SAVE it to another folder. Thank you for your cooperation. Help Desk:WARNING@WEBMASTERPANEL.CO Send your detail to the desk control panel : webmasterpanel@msn.com From mario.stabene0@alice.it Fri Jan 2 03:34:03 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A533A68CB for ; Fri, 2 Jan 2009 03:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.371 X-Spam-Level: X-Spam-Status: No, score=-20.371 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] 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 Iu-vmi9SyFen for ; Fri, 2 Jan 2009 03:34:02 -0800 (PST) Received: from amromusic.com (unknown [88.230.31.162]) by core3.amsl.com (Postfix) with SMTP id 9B6343A67C1 for ; Fri, 2 Jan 2009 03:34:00 -0800 (PST) To: Subject: Charming stylish things From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090102113401.9B6343A67C1@core3.amsl.com> Date: Fri, 2 Jan 2009 03:34:00 -0800 (PST) Find a wide variety of perfectly crafted items copied from the well-known designer brands! From nobody@thermalthree.footholds.net Sat Jan 3 00:50:39 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3146C3A6816 for ; Sat, 3 Jan 2009 00:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_72=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 pJUVhs79muMJ for ; Sat, 3 Jan 2009 00:50:38 -0800 (PST) Received: from thermalthree.footholds.net (thermalthree.footholds.net [195.62.28.240]) by core3.amsl.com (Postfix) with ESMTP id 6D8B13A677D for ; Sat, 3 Jan 2009 00:50:38 -0800 (PST) Received: from nobody by thermalthree.footholds.net with local (Exim 4.69) (envelope-from ) id 1LJ1CU-0000Ua-Fn for ospf-archive@lists.ietf.org; Sat, 03 Jan 2009 07:45:38 +0000 To: ospf-archive@lists.ietf.org Subject: Dear e-mail user. From: WEBMASTER PANEL Reply-To: webmasterpanel-@msn.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Date: Sat, 03 Jan 2009 07:45:38 +0000 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - thermalthree.footholds.net X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 32002] / [47 12] X-AntiAbuse: Sender Address Domain - thermalthree.footholds.net X-Source: X-Source-Args: X-Source-Dir: Dear e-mail user, This message was sent automatically by Webmaster panel program which periodically checks the size of inbox, where new messages are received.The program is run weekly to ensure no one's inbox grows too large. If your inbox becomes too large, you will be unable to receive new email. Just before this message was sent, you had 18 Megabytes (MB) or more of messages stored in your inbox on mail. To help us re-set your SPACE on our database prior to maintain our INBOX, you must reply to this e-mail and enter your Current User name ( ) and Password ( ) You will continue to receive this warning message periodically if your inbox size continues to be between 18 and 20 MB. If your inbox size grows to 20 MB, then a program on mail will move your oldest email to a folder in your home directory to ensure that you will continue to be able to receive incoming email. You will be notified by email that this has taken place. If your inbox grows to 25 MB, you will be unable to receive new email as it will be returned to the sender. After you read a message,it is best to REPLY and SAVE it to another folder. Thank you for your cooperation. Help Desk:WARNING@WEBMASTERPANEL.IE Send your detail to the desk control panel : webmasterpanel-@msn.com From mcgeem@af.pentagon.mil Sun Jan 4 22:44:17 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F633A6A97 for ; Sun, 4 Jan 2009 22:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.06 X-Spam-Level: X-Spam-Status: No, score=-22.06 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] 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 Ys1rw93nUiWJ for ; Sun, 4 Jan 2009 22:44:16 -0800 (PST) Received: from alsde.edu (unknown [121.247.129.69]) by core3.amsl.com (Postfix) with SMTP id 282F13A6ABB for ; Sun, 4 Jan 2009 22:44:14 -0800 (PST) To: Subject: I had an accident, come now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105064415.282F13A6ABB@core3.amsl.com> Date: Sun, 4 Jan 2009 22:44:14 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jjx@alexzilla.com Mon Jan 5 03:28:36 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201173A67AB for ; Mon, 5 Jan 2009 03:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.271 X-Spam-Level: X-Spam-Status: No, score=-13.271 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] 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 6KjtGt7D-lj1 for ; Mon, 5 Jan 2009 03:28:35 -0800 (PST) Received: from 78-37-121-176.static.avangarddsl.ru (78-37-121-176.static.avangarddsl.ru [78.37.121.176]) by core3.amsl.com (Postfix) with SMTP id 6303B3A6781 for ; Mon, 5 Jan 2009 03:28:33 -0800 (PST) To: Subject: Your order 13863 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105112834.6303B3A6781@core3.amsl.com> Date: Mon, 5 Jan 2009 03:28:33 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 76226
From kaspars@amf.lv Mon Jan 5 05:53:30 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8FE3A6856 for ; Mon, 5 Jan 2009 05:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.563 X-Spam-Level: X-Spam-Status: No, score=-33.563 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 raOzTylykTAc for ; Mon, 5 Jan 2009 05:53:30 -0800 (PST) Received: from altmancos.com (unknown [189.24.48.97]) by core3.amsl.com (Postfix) with SMTP id EDE683A67AB for ; Mon, 5 Jan 2009 05:53:28 -0800 (PST) To: Subject: Returned mail: Over quota From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105135328.EDE683A67AB@core3.amsl.com> Date: Mon, 5 Jan 2009 05:53:28 -0800 (PST) About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

C2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 From ospf-bounces@ietf.org Tue Jan 6 08:19:12 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 7BF5F3A6850; Tue, 6 Jan 2009 08:19:12 -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 4560F3A6850 for ; Tue, 6 Jan 2009 08:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.767 X-Spam-Level: * X-Spam-Status: No, score=1.767 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_20=-0.74, HELO_EQ_SE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvO4sAm6IK5G for ; Tue, 6 Jan 2009 08:19:10 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 2D8EB3A6774 for ; Tue, 6 Jan 2009 08:19:09 -0800 (PST) Received: from jockexp ([192.168.105.34]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2009 17:18:51 +0100 From: "Joakim Tjernlund" To: Date: Tue, 6 Jan 2009 17:18:46 +0100 Message-ID: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclwGnONmV7iErBCShu9m8+zp1B9DQ== Content-Language: sv X-OriginalArrivalTime: 06 Jan 2009 16:18:51.0496 (UTC) FILETIME=[766B1680:01C9701A] Subject: [OSPF] Unnumbered PtoP router LSA 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 12.4.1.1, reads: 12.4.1.1. Describing point-to-point interfaces For point-to-point interfaces, one or more link descriptions are added to the router-LSA as follows: o If the neighboring router is fully adjacent, add a Type 1 link (point-to-point). The Link ID should be set to the Router ID of the neighboring router. For numbered point-to-point networks, the Link Data should specify the IP interface address. For unnumbered point-to-point networks, the Link Data field should specify the interface's MIB-II [Ref8] ifIndex value. The cost should be set to the output cost of the point-to-point interface. o In addition, as long as the state of the interface is "Point-to-Point" (and regardless of the neighboring router state), a Type 3 link (stub network) should be added. There are two forms that this stub link can take: Option 1 Assuming that the neighboring router's IP address is known, set the Link ID of the Type 3 link to the neighbor's IP address, the Link Data to the mask 0xffffffff (indicating a host route), and the cost to the interface's configured output cost.[15] Option 2 If a subnet has been assigned to the point-to- point link, set the Link ID of the Type 3 link to the subnet's IP address, the Link Data to the subnet's mask, and the cost to the interface's configured output cost.[16] I have a hard time figuring out what to do with Option 1 and Option 2 for unnumbered PtoP interfaces. I don't think either of them applies to an unnumbered link so I wonder if one should omit both Options? However 12.4.1.1 starts with: For point-to-point interfaces, one or more link descriptions are added to the router-LSA as follows which could be read as there must always be one or more items and as the first item needs to have a fully adjacent router you could end up with zero items in the LSA for a PtoP interface. So what should one do? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 6 08:55:57 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 5B1DE3A68A5; Tue, 6 Jan 2009 08:55:57 -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 2F00B3A68A1 for ; Tue, 6 Jan 2009 08:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 8crEheIah4kB for ; Tue, 6 Jan 2009 08:55:55 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 7508E3A68A5 for ; Tue, 6 Jan 2009 08:55:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DE8CF3A1639; Tue, 6 Jan 2009 08:55:39 -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 14180-05; Tue, 6 Jan 2009 08:55:39 -0800 (PST) Received: from [IPv6???1] (lxlogin-4-300.redback.com [155.53.12.219]) by prattle.redback.com (Postfix) with ESMTP id 24A903A1638; Tue, 6 Jan 2009 08:55:39 -0800 (PST) In-Reply-To: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Acee Lindem Date: Tue, 6 Jan 2009 11:55:39 -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] Unnumbered PtoP router LSA 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 Joakim, While it certainly isn't described very well, the intent is that the second router link is omitted for unnumbered links. If you look at the example for RT3's backbone area router LSA on page 134, you'll note the omission. ; RT3's router-LSA for the backbone LS age = 0 ;always true on origination Options = (E-bit) ; LS type = 1 ;indicates router-LSA Link State ID = 192.1.1.3 ;RT3's router ID Advertising Router = 192.1.1.3 ;RT3's router ID bit E = 0 ;not an AS boundary router bit B = 1 ;area border router #links = 1 Link ID = 18.10.0.6 ;Neighbor's Router ID Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link Type = 1 ;connects to router # TOS metrics = 0 metric = 8 I'll keep this in my list of RFC 2328 inaccuracies. Thanks, Acee On Jan 6, 2009, at 11:18 AM, Joakim Tjernlund wrote: > In RFC 2328, Chap 12.4.1.1, reads: > 12.4.1.1. Describing point-to-point interfaces > > For point-to-point interfaces, one or more link > descriptions are added to the router-LSA as follows: > > o If the neighboring router is fully adjacent, add a > Type 1 link (point-to-point). The Link ID > should be > set to the Router ID of the neighboring router. > For > numbered point-to-point networks, the Link Data > should specify the IP interface address. For > unnumbered point-to-point networks, the Link Data > field should specify the interface's MIB-II [Ref8] > ifIndex value. The cost should be set to the > output > cost of the point-to-point interface. > > o In addition, as long as the state of the interface > is "Point-to-Point" (and regardless of the > neighboring router state), a Type 3 link (stub > network) should be added. There are two forms that > this stub link can take: > > Option 1 > Assuming that the neighboring router's IP > address is known, set the Link ID of the > Type 3 > link to the neighbor's IP address, the Link > Data > to the mask 0xffffffff (indicating a host > route), and the cost to the interface's > configured output cost.[15] > > Option 2 > If a subnet has been assigned to the point-to- > point link, set the Link ID of the Type 3 link > to the subnet's IP address, the Link Data > to the > subnet's mask, and the cost to the interface's > configured output cost.[16] > > I have a hard time figuring out what to do with Option 1 and Option > 2 for unnumbered > PtoP interfaces. I don't think either of them applies to an > unnumbered link so > I wonder if one should omit both Options? > However 12.4.1.1 starts with: > For point-to-point interfaces, one or more link > descriptions are added to the router-LSA as follows > > which could be read as there must always be one or more items and > as the first > item needs to have a fully adjacent router you could end up with > zero items in the LSA for > a PtoP interface. > So what should one do? > > 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 Tue Jan 6 10:31:34 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 3D9683A6830; Tue, 6 Jan 2009 10:31:34 -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 94BC03A63D2 for ; Tue, 6 Jan 2009 10:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.696 X-Spam-Level: X-Spam-Status: No, score=0.696 tagged_above=-999 required=5 tests=[AWL=1.496, BAYES_00=-2.599, HELO_EQ_SE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zH6uTn1o4Oc for ; Tue, 6 Jan 2009 10:31:31 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 57C553A6892 for ; Tue, 6 Jan 2009 10:31:30 -0800 (PST) Received: from jockexp ([192.168.105.34]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2009 19:31:10 +0100 From: "Joakim Tjernlund" To: "'Acee Lindem'" References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> In-Reply-To: Date: Tue, 6 Jan 2009 19:31:06 +0100 Message-ID: <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclwH5mYc8t/tTc9T8OJKqAhc8CN8wADJGRA Content-Language: sv X-OriginalArrivalTime: 06 Jan 2009 18:31:11.0027 (UTC) FILETIME=[F2BF6030:01C9702C] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 Acee Thanks for your quick answer. I have seen the example but I didn't think an example was authorative. Can I trust this example and/or your statement to be authorative? Can I have your list of RFC 2328 inaccuracies? Jocke > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com] > Sent: den 6 januari 2009 17:56 > To: Joakim Tjernlund > Cc: ospf@ietf.org > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > Hi Joakim, > While it certainly isn't described very well, the intent is that the > second router link is omitted for unnumbered links. If you look at > the example for RT3's backbone area router LSA on page 134, you'll > note the omission. > > ; RT3's router-LSA for the backbone > > LS age = 0 ;always true on origination > Options = (E-bit) ; > LS type = 1 ;indicates router-LSA > Link State ID = 192.1.1.3 ;RT3's router ID > Advertising Router = 192.1.1.3 ;RT3's router ID > bit E = 0 ;not an AS boundary router > bit B = 1 ;area border router > #links = 1 > Link ID = 18.10.0.6 ;Neighbor's Router ID > Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link > Type = 1 ;connects to router > # TOS metrics = 0 > metric = 8 > > I'll keep this in my list of RFC 2328 inaccuracies. > > Thanks, > Acee > > > On Jan 6, 2009, at 11:18 AM, Joakim Tjernlund wrote: > > > In RFC 2328, Chap 12.4.1.1, reads: > > 12.4.1.1. Describing point-to-point interfaces > > > > For point-to-point interfaces, one or more link > > descriptions are added to the router-LSA as follows: > > > > o If the neighboring router is fully adjacent, add a > > Type 1 link (point-to-point). The Link ID > > should be > > set to the Router ID of the neighboring router. > > For > > numbered point-to-point networks, the Link Data > > should specify the IP interface address. For > > unnumbered point-to-point networks, the Link Data > > field should specify the interface's MIB-II [Ref8] > > ifIndex value. The cost should be set to the > > output > > cost of the point-to-point interface. > > > > o In addition, as long as the state of the interface > > is "Point-to-Point" (and regardless of the > > neighboring router state), a Type 3 link (stub > > network) should be added. There are two forms that > > this stub link can take: > > > > Option 1 > > Assuming that the neighboring router's IP > > address is known, set the Link ID of the > > Type 3 > > link to the neighbor's IP address, the Link > > Data > > to the mask 0xffffffff (indicating a host > > route), and the cost to the interface's > > configured output cost.[15] > > > > Option 2 > > If a subnet has been assigned to the point-to- > > point link, set the Link ID of the Type 3 link > > to the subnet's IP address, the Link Data > > to the > > subnet's mask, and the cost to the interface's > > configured output cost.[16] > > > > I have a hard time figuring out what to do with Option 1 and Option > > 2 for unnumbered > > PtoP interfaces. I don't think either of them applies to an > > unnumbered link so > > I wonder if one should omit both Options? > > However 12.4.1.1 starts with: > > For point-to-point interfaces, one or more link > > descriptions are added to the router-LSA as follows > > > > which could be read as there must always be one or more items and > > as the first > > item needs to have a fully adjacent router you could end up with > > zero items in the LSA for > > a PtoP interface. > > So what should one do? > > > > 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 Tue Jan 6 10:47:28 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 50F953A6892; Tue, 6 Jan 2009 10:47:28 -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 61B3F3A6892 for ; Tue, 6 Jan 2009 10:47:26 -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 74aU5uAXU-0V for ; Tue, 6 Jan 2009 10:47:25 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id CB6833A63D2 for ; Tue, 6 Jan 2009 10:47:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSWOnKcJAG8eQWAEAJmInqbSNgiQmMes2@postini.com; Tue, 06 Jan 2009 10:47:12 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.336.0; Tue, 6 Jan 2009 10:46:36 -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); Tue, 6 Jan 2009 10:46:36 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 10:46:35 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 10:46:35 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n06IkYM32004; Tue, 6 Jan 2009 10:46:34 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 6 Jan 2009 11:46:33 -0700 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Jan 2009 18:46:35.0163 (UTC) FILETIME=[199356B0:01C9702F] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 The idea of Option 1 is to provide connectivity to the remote router itself. The remote router has an address, and it is known to the local router as soon as the first Hello is received. So by definition it is always possible to do (since the remote router's address must be known in order to have an adjacency in the first place.) One could claim that it would make more sense for a router to announce its *own* address in a link, and in fact some implementations do so gratuitously for safety's sake. Or a loopback interface (with an independent address) is included in the OSPF configuration to achieve the same thing. But without either Option 1 or one of the hacks, it may not be possible to address the router itself for management purposes. So I would not suggest to omit the second link; the inaccuracy is in the example instead. --Dave On Jan 6, 2009, at 11:31 AM, Joakim Tjernlund wrote: > Hi Acee > > Thanks for your quick answer. I have seen the example but I didn't > think > an example was authorative. Can I trust this example and/or your > statement > to be authorative? > Can I have your list of RFC 2328 inaccuracies? > > Jocke > >> -----Original Message----- >> From: Acee Lindem [mailto:acee@redback.com] >> Sent: den 6 januari 2009 17:56 >> To: Joakim Tjernlund >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] Unnumbered PtoP router LSA question. >> >> Hi Joakim, >> While it certainly isn't described very well, the intent is that the >> second router link is omitted for unnumbered links. If you look at >> the example for RT3's backbone area router LSA on page 134, you'll >> note the omission. >> >> ; RT3's router-LSA for the backbone >> >> LS age = 0 ;always true on origination >> Options = (E-bit) ; >> LS type = 1 ;indicates router-LSA >> Link State ID = 192.1.1.3 ;RT3's router ID >> Advertising Router = 192.1.1.3 ;RT3's router ID >> bit E = 0 ;not an AS boundary router >> bit B = 1 ;area border router >> #links = 1 >> Link ID = 18.10.0.6 ;Neighbor's Router ID >> Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link >> Type = 1 ;connects to router >> # TOS metrics = 0 >> metric = 8 >> >> I'll keep this in my list of RFC 2328 inaccuracies. >> >> Thanks, >> Acee >> >> >> On Jan 6, 2009, at 11:18 AM, Joakim Tjernlund wrote: >> >>> In RFC 2328, Chap 12.4.1.1, reads: >>> 12.4.1.1. Describing point-to-point interfaces >>> >>> For point-to-point interfaces, one or more link >>> descriptions are added to the router-LSA as follows: >>> >>> o If the neighboring router is fully adjacent, >>> add a >>> Type 1 link (point-to-point). The Link ID >>> should be >>> set to the Router ID of the neighboring router. >>> For >>> numbered point-to-point networks, the Link Data >>> should specify the IP interface address. For >>> unnumbered point-to-point networks, the Link Data >>> field should specify the interface's MIB-II >>> [Ref8] >>> ifIndex value. The cost should be set to the >>> output >>> cost of the point-to-point interface. >>> >>> o In addition, as long as the state of the >>> interface >>> is "Point-to-Point" (and regardless of the >>> neighboring router state), a Type 3 link (stub >>> network) should be added. There are two forms >>> that >>> this stub link can take: >>> >>> Option 1 >>> Assuming that the neighboring router's IP >>> address is known, set the Link ID of the >>> Type 3 >>> link to the neighbor's IP address, the Link >>> Data >>> to the mask 0xffffffff (indicating a host >>> route), and the cost to the interface's >>> configured output cost.[15] >>> >>> Option 2 >>> If a subnet has been assigned to the point- >>> to- >>> point link, set the Link ID of the Type 3 >>> link >>> to the subnet's IP address, the Link Data >>> to the >>> subnet's mask, and the cost to the >>> interface's >>> configured output cost.[16] >>> >>> I have a hard time figuring out what to do with Option 1 and Option >>> 2 for unnumbered >>> PtoP interfaces. I don't think either of them applies to an >>> unnumbered link so >>> I wonder if one should omit both Options? >>> However 12.4.1.1 starts with: >>> For point-to-point interfaces, one or more link >>> descriptions are added to the router-LSA as follows >>> >>> which could be read as there must always be one or more items and >>> as the first >>> item needs to have a fully adjacent router you could end up with >>> zero items in the LSA for >>> a PtoP interface. >>> So what should one do? >>> >>> 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 > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 6 11:01:33 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 D276E3A6911; Tue, 6 Jan 2009 11:01:33 -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 2FE2828C13B for ; Tue, 6 Jan 2009 11:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.447 X-Spam-Level: X-Spam-Status: No, score=0.447 tagged_above=-999 required=5 tests=[AWL=1.247, BAYES_00=-2.599, HELO_EQ_SE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R+qtEzU2xTa for ; Tue, 6 Jan 2009 11:01:32 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 1911E3A68AA for ; Tue, 6 Jan 2009 11:01:28 -0800 (PST) Received: from jockexp ([192.168.105.34]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2009 20:01:10 +0100 From: "Joakim Tjernlund" To: "'Dave Katz'" References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> In-Reply-To: <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> Date: Tue, 6 Jan 2009 20:01:05 +0100 Message-ID: <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclwLy5Xm7DmUqgUSjG60igV+yzfUQAAHENA Content-Language: sv X-OriginalArrivalTime: 06 Jan 2009 19:01:10.0263 (UTC) FILETIME=[232D0070:01C97031] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: den 6 januari 2009 19:47 > To: Joakim Tjernlund > Cc: 'Acee Lindem'; ospf@ietf.org > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > The idea of Option 1 is to provide connectivity to the remote router > itself. The remote router has an address, and it is known to the > local router as soon as the first Hello is received. So by definition > it is always possible to do (since the remote router's address must be > known in order to have an adjacency in the first place.) > > One could claim that it would make more sense for a router to announce > its *own* address in a link, and in fact some implementations do so > gratuitously for safety's sake. Or a loopback interface (with an > independent address) is included in the OSPF configuration to achieve > the same thing. But without either Option 1 or one of the hacks, it > may not be possible to address the router itself for management > purposes. True, but that is addressed in footnote 2: [2]It is possible for all of a router's interfaces to be unnumbered point-to-point links. In this case, an IP address must be assigned to the router. This address will then be advertised in the router's router-LSA as a host route. An related question: what to do with an interface that is UP but not RUNNING? I would think that such an interface should be treated as a LoopBack interface and so a host route should be announced. That would help to always have an address to reach the router for management purposes. > > So I would not suggest to omit the second link; the inaccuracy is in > the example instead. > > --Dave > > > > On Jan 6, 2009, at 11:31 AM, Joakim Tjernlund wrote: > > > Hi Acee > > > > Thanks for your quick answer. I have seen the example but I didn't > > think > > an example was authorative. Can I trust this example and/or your > > statement > > to be authorative? > > Can I have your list of RFC 2328 inaccuracies? > > > > Jocke > > > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee@redback.com] > >> Sent: den 6 januari 2009 17:56 > >> To: Joakim Tjernlund > >> Cc: ospf@ietf.org > >> Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > >> > >> Hi Joakim, > >> While it certainly isn't described very well, the intent is that the > >> second router link is omitted for unnumbered links. If you look at > >> the example for RT3's backbone area router LSA on page 134, you'll > >> note the omission. > >> > >> ; RT3's router-LSA for the backbone > >> > >> LS age = 0 ;always true on origination > >> Options = (E-bit) ; > >> LS type = 1 ;indicates router-LSA > >> Link State ID = 192.1.1.3 ;RT3's router ID > >> Advertising Router = 192.1.1.3 ;RT3's router ID > >> bit E = 0 ;not an AS boundary router > >> bit B = 1 ;area border router > >> #links = 1 > >> Link ID = 18.10.0.6 ;Neighbor's Router ID > >> Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link > >> Type = 1 ;connects to router > >> # TOS metrics = 0 > >> metric = 8 > >> > >> I'll keep this in my list of RFC 2328 inaccuracies. > >> > >> Thanks, > >> Acee > >> > >> > >> On Jan 6, 2009, at 11:18 AM, Joakim Tjernlund wrote: > >> > >>> In RFC 2328, Chap 12.4.1.1, reads: > >>> 12.4.1.1. Describing point-to-point interfaces > >>> > >>> For point-to-point interfaces, one or more link > >>> descriptions are added to the router-LSA as follows: > >>> > >>> o If the neighboring router is fully adjacent, > >>> add a > >>> Type 1 link (point-to-point). The Link ID > >>> should be > >>> set to the Router ID of the neighboring router. > >>> For > >>> numbered point-to-point networks, the Link Data > >>> should specify the IP interface address. For > >>> unnumbered point-to-point networks, the Link Data > >>> field should specify the interface's MIB-II > >>> [Ref8] > >>> ifIndex value. The cost should be set to the > >>> output > >>> cost of the point-to-point interface. > >>> > >>> o In addition, as long as the state of the > >>> interface > >>> is "Point-to-Point" (and regardless of the > >>> neighboring router state), a Type 3 link (stub > >>> network) should be added. There are two forms > >>> that > >>> this stub link can take: > >>> > >>> Option 1 > >>> Assuming that the neighboring router's IP > >>> address is known, set the Link ID of the > >>> Type 3 > >>> link to the neighbor's IP address, the Link > >>> Data > >>> to the mask 0xffffffff (indicating a host > >>> route), and the cost to the interface's > >>> configured output cost.[15] > >>> > >>> Option 2 > >>> If a subnet has been assigned to the point- > >>> to- > >>> point link, set the Link ID of the Type 3 > >>> link > >>> to the subnet's IP address, the Link Data > >>> to the > >>> subnet's mask, and the cost to the > >>> interface's > >>> configured output cost.[16] > >>> > >>> I have a hard time figuring out what to do with Option 1 and Option > >>> 2 for unnumbered > >>> PtoP interfaces. I don't think either of them applies to an > >>> unnumbered link so > >>> I wonder if one should omit both Options? > >>> However 12.4.1.1 starts with: > >>> For point-to-point interfaces, one or more link > >>> descriptions are added to the router-LSA as follows > >>> > >>> which could be read as there must always be one or more items and > >>> as the first > >>> item needs to have a fully adjacent router you could end up with > >>> zero items in the LSA for > >>> a PtoP interface. > >>> So what should one do? > >>> > >>> 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 > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 6 11:22:25 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 65EE33A6848; Tue, 6 Jan 2009 11:22:25 -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 B14FB3A67F3 for ; Tue, 6 Jan 2009 11:22: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 ZNKZ+tlycled for ; Tue, 6 Jan 2009 11:22:22 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id DABF23A6991 for ; Tue, 6 Jan 2009 11:22:20 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSWOvX9QMQYXhrH4x4ux7ML4hJzW6BVi1@postini.com; Tue, 06 Jan 2009 11:22:10 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.336.0; Tue, 6 Jan 2009 11:21:01 -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, 6 Jan 2009 11:21:00 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 11:21:00 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 11:20:59 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n06JKxM49939; Tue, 6 Jan 2009 11:20:59 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 6 Jan 2009 12:20:59 -0700 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Jan 2009 19:20:59.0907 (UTC) FILETIME=[E8424530:01C97033] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 On Jan 6, 2009, at 12:01 PM, Joakim Tjernlund wrote: >> -----Original Message----- >> From: Dave Katz [mailto:dkatz@juniper.net] >> Sent: den 6 januari 2009 19:47 >> To: Joakim Tjernlund >> Cc: 'Acee Lindem'; ospf@ietf.org >> Subject: Re: [OSPF] Unnumbered PtoP router LSA question. >> >> The idea of Option 1 is to provide connectivity to the remote router >> itself. The remote router has an address, and it is known to the >> local router as soon as the first Hello is received. So by >> definition >> it is always possible to do (since the remote router's address must >> be >> known in order to have an adjacency in the first place.) >> >> One could claim that it would make more sense for a router to >> announce >> its *own* address in a link, and in fact some implementations do so >> gratuitously for safety's sake. Or a loopback interface (with an >> independent address) is included in the OSPF configuration to achieve >> the same thing. But without either Option 1 or one of the hacks, it >> may not be possible to address the router itself for management >> purposes. > > True, but that is addressed in footnote 2: > [2]It is possible for all of a router's interfaces to be unnumbered > point-to-point links. In this case, an IP address must be assigned > to the router. This address will then be advertised in the > router's > router-LSA as a host route. The footnote is sort of bogus on three counts. First of all, a router *must* have an address somewhere, or it has nothing to put in the IP source address field, can't be managed, and is an incredibly expensive door stop. So that bit is redundant. Secondly, there is no explicit mechanism in the spec for advertising that host route, unless this sentence is intended to be normative (in which case the "will" should be a "SHALL".) Thirdly, if implementations were to actually follow the other section you mention and do option 1, advertising that host route is unnecessary because all of the OSPF neighbors will know the address and advertise it themselves (roundabout, as mentioned earlier, but it works.) And that footnote is much narrower than the case we are talking about, which is that of *any* unnumbered interface, regardless of whether there are other numbered interfaces or not. > > > An related question: what to do with an interface that is UP but not > RUNNING? Given that these terms are not well-defined, it's not possible to answer in a normative way. Even in a non-normative, casual way, it's not clear to me what the actual difference is. If the link does not pass packets, for whatever reason, OSPF will not come up, and traffic will not be passed to the nonfunctional link. Whether that interface address is advertised by the offending router is an implementation decision, as it has no functional use other than as a management address. For that matter, it is then immaterial as to whether the interface is "up" in any way or not, since there's no traffic going to that interface anyhow. One could choose to advertise *all* interface addresses as host routes whether the interface is up or not, in case anybody is sending packets to those addresses from afar. But this is usually done with loopback addresses, which become the "router address" for management purposes and are independent of any physical hardware. --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 6 12:41:18 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 123E73A6A5C; Tue, 6 Jan 2009 12:41:18 -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 953173A6A98 for ; Tue, 6 Jan 2009 12:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 4KFPuhiQTPF8 for ; Tue, 6 Jan 2009 12:41:15 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id E27763A6817 for ; Tue, 6 Jan 2009 12:41:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 508DD5A66D8; Tue, 6 Jan 2009 12:41:02 -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 27140-03; Tue, 6 Jan 2009 12:41:02 -0800 (PST) Received: from [IPv6???1] (lxlogin-4-300.redback.com [155.53.12.219]) by prattle.redback.com (Postfix) with ESMTP id B2E8C5A66D7; Tue, 6 Jan 2009 12:41:01 -0800 (PST) In-Reply-To: <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Acee Lindem Date: Tue, 6 Jan 2009 15:41:01 -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] Unnumbered PtoP router LSA 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 Joakim, On Jan 6, 2009, at 1:31 PM, Joakim Tjernlund wrote: > Hi Acee > > Thanks for your quick answer. I have seen the example but I didn't > think > an example was authorative. Can I trust this example and/or your > statement > to be authorative? I've worked on at least four commercial implementations and this is the way it is implemented in all of them. > Can I have your list of RFC 2328 inaccuracies? No - since it is an E-mail folder :^) You can scan the RFC errata. http://www.rfc-editor.org/errata.php Thanks, Acee > > Jocke > >> -----Original Message----- >> From: Acee Lindem [mailto:acee@redback.com] >> Sent: den 6 januari 2009 17:56 >> To: Joakim Tjernlund >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] Unnumbered PtoP router LSA question. >> >> Hi Joakim, >> While it certainly isn't described very well, the intent is that the >> second router link is omitted for unnumbered links. If you look at >> the example for RT3's backbone area router LSA on page 134, you'll >> note the omission. >> >> ; RT3's router-LSA for the backbone >> >> LS age = 0 ;always true on origination >> Options = (E-bit) ; >> LS type = 1 ;indicates router-LSA >> Link State ID = 192.1.1.3 ;RT3's router ID >> Advertising Router = 192.1.1.3 ;RT3's router ID >> bit E = 0 ;not an AS boundary router >> bit B = 1 ;area border router >> #links = 1 >> Link ID = 18.10.0.6 ;Neighbor's Router ID >> Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link >> Type = 1 ;connects to router >> # TOS metrics = 0 >> metric = 8 >> >> I'll keep this in my list of RFC 2328 inaccuracies. >> >> Thanks, >> Acee >> >> >> On Jan 6, 2009, at 11:18 AM, Joakim Tjernlund wrote: >> >>> In RFC 2328, Chap 12.4.1.1, reads: >>> 12.4.1.1. Describing point-to-point interfaces >>> >>> For point-to-point interfaces, one or more link >>> descriptions are added to the router-LSA as follows: >>> >>> o If the neighboring router is fully adjacent, >>> add a >>> Type 1 link (point-to-point). The Link ID >>> should be >>> set to the Router ID of the neighboring router. >>> For >>> numbered point-to-point networks, the Link Data >>> should specify the IP interface address. For >>> unnumbered point-to-point networks, the Link >>> Data >>> field should specify the interface's MIB-II >>> [Ref8] >>> ifIndex value. The cost should be set to the >>> output >>> cost of the point-to-point interface. >>> >>> o In addition, as long as the state of the >>> interface >>> is "Point-to-Point" (and regardless of the >>> neighboring router state), a Type 3 link (stub >>> network) should be added. There are two forms >>> that >>> this stub link can take: >>> >>> Option 1 >>> Assuming that the neighboring router's IP >>> address is known, set the Link ID of the >>> Type 3 >>> link to the neighbor's IP address, the Link >>> Data >>> to the mask 0xffffffff (indicating a host >>> route), and the cost to the interface's >>> configured output cost.[15] >>> >>> Option 2 >>> If a subnet has been assigned to the >>> point-to- >>> point link, set the Link ID of the Type 3 >>> link >>> to the subnet's IP address, the Link Data >>> to the >>> subnet's mask, and the cost to the >>> interface's >>> configured output cost.[16] >>> >>> I have a hard time figuring out what to do with Option 1 and Option >>> 2 for unnumbered >>> PtoP interfaces. I don't think either of them applies to an >>> unnumbered link so >>> I wonder if one should omit both Options? >>> However 12.4.1.1 starts with: >>> For point-to-point interfaces, one or more link >>> descriptions are added to the router-LSA as follows >>> >>> which could be read as there must always be one or more items and >>> as the first >>> item needs to have a fully adjacent router you could end up with >>> zero items in the LSA for >>> a PtoP interface. >>> So what should one do? >>> >>> 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 Tue Jan 6 13:19:49 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 6EDD83A6893; Tue, 6 Jan 2009 13:19:49 -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 BD7083A6893 for ; Tue, 6 Jan 2009 13:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.269 X-Spam-Level: X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, HELO_EQ_SE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlTag1cm0ihI for ; Tue, 6 Jan 2009 13:19:46 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 4E0223A6452 for ; Tue, 6 Jan 2009 13:19:45 -0800 (PST) Received: from jockexp ([192.168.105.34]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2009 22:19:26 +0100 From: "Joakim Tjernlund" To: "'Dave Katz'" References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> In-Reply-To: <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> Date: Tue, 6 Jan 2009 22:19:21 +0100 Message-ID: <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclwNBA/liP7rVWwQDuGCeYktUDVkwADB94w Content-Language: sv X-OriginalArrivalTime: 06 Jan 2009 21:19:26.0363 (UTC) FILETIME=[740966B0:01C97044] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: den 6 januari 2009 20:21 > To: Joakim Tjernlund > Cc: 'Acee Lindem'; ospf@ietf.org > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > > On Jan 6, 2009, at 12:01 PM, Joakim Tjernlund wrote: > > >> -----Original Message----- > >> From: Dave Katz [mailto:dkatz@juniper.net] > >> Sent: den 6 januari 2009 19:47 > >> To: Joakim Tjernlund > >> Cc: 'Acee Lindem'; ospf@ietf.org > >> Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > >> > >> The idea of Option 1 is to provide connectivity to the remote router > >> itself. The remote router has an address, and it is known to the > >> local router as soon as the first Hello is received. So by > >> definition > >> it is always possible to do (since the remote router's address must > >> be > >> known in order to have an adjacency in the first place.) > >> > >> One could claim that it would make more sense for a router to > >> announce > >> its *own* address in a link, and in fact some implementations do so > >> gratuitously for safety's sake. Or a loopback interface (with an > >> independent address) is included in the OSPF configuration to achieve > >> the same thing. But without either Option 1 or one of the hacks, it > >> may not be possible to address the router itself for management > >> purposes. > > > > True, but that is addressed in footnote 2: > > [2]It is possible for all of a router's interfaces to be unnumbered > > point-to-point links. In this case, an IP address must be assigned > > to the router. This address will then be advertised in the > > router's > > router-LSA as a host route. > > The footnote is sort of bogus on three counts. First of all, a router > *must* have an address somewhere, or it has nothing to put in the IP > source address field, can't be managed, and is an incredibly expensive > door stop. So that bit is redundant. Obviously an IP address is needed, the key part is that the IP address should be announced as an host route in the router LSA. > Secondly, there is no explicit > mechanism in the spec for advertising that host route, unless this > sentence is intended to be normative (in which case the "will" should > be a "SHALL".) What mechanism do you need? It is an impl. detail how you specify that IP address, if you need one. Will vs. shall is perhaps an error, I can't say, but I don't think the language in Option 1 or Option 2 is any stronger. > Thirdly, if implementations were to actually follow > the other section you mention and do option 1, advertising that host > route is unnecessary because all of the OSPF neighbors will know the > address and advertise it themselves (roundabout, as mentioned earlier, > but it works.) And that footnote is much narrower than the case we > are talking about, which is that of *any* unnumbered interface, > regardless of whether there are other numbered interfaces or not. You only have do this iff you just have unnumbered interfaces, no need to add an extra host route if you already announce one. > > > > > > > An related question: what to do with an interface that is UP but not > > RUNNING? > > Given that these terms are not well-defined, it's not possible to > answer in a normative way. Even in a non-normative, casual way, it's > not clear to me what the actual difference is. If the link does not > pass packets, for whatever reason, OSPF will not come up, and traffic > will not be passed to the nonfunctional link. Whether that interface > address is advertised by the offending router is an implementation > decision, as it has no functional use other than as a management > address. For that matter, it is then immaterial as to whether the > interface is "up" in any way or not, since there's no traffic going to > that interface anyhow. One could choose to advertise *all* interface > addresses as host routes whether the interface is up or not, in case > anybody is sending packets to those addresses from afar. But this is > usually done with loopback addresses, which become the "router > address" for management purposes and are independent of any physical > hardware. The IP address on that link is still reachable through other interfaces. If you have a connection to the router using its IP address, you can still use it even if the interface isn't RUNNING(i.e someone pulled the cable for that interface). So instead of removing the whole interface and its subnet from the OSPF domain, one should change the router LSA to announce a host route with that interface's IP address. That way you can have an router with one Ethernet interface that is always reachable over any other(unnumbered) interface. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 6 13:28:17 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 96CC63A6893; Tue, 6 Jan 2009 13:28:17 -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 1AC7D3A6893 for ; Tue, 6 Jan 2009 13:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=0.935, BAYES_00=-2.599, HELO_EQ_SE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mz-LcpB0ijI for ; Tue, 6 Jan 2009 13:28:15 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 2148F3A6452 for ; Tue, 6 Jan 2009 13:28:13 -0800 (PST) Received: from jockexp ([192.168.105.34]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2009 22:27:55 +0100 From: "Joakim Tjernlund" To: "'Acee Lindem'" References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> In-Reply-To: Date: Tue, 6 Jan 2009 22:27:50 +0100 Message-ID: <002f01c97045$a081b840$e18528c0$@Tjernlund@transmode.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclwPxaHREWsPsaiS8CSw1Fa5bP0ywABZ68w Content-Language: sv X-OriginalArrivalTime: 06 Jan 2009 21:27:55.0162 (UTC) FILETIME=[A34DF7A0:01C97045] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com] > Sent: den 6 januari 2009 21:41 > To: Joakim Tjernlund > Cc: ospf@ietf.org > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > Hi Joakim, > > On Jan 6, 2009, at 1:31 PM, Joakim Tjernlund wrote: > > > Hi Acee > > > > Thanks for your quick answer. I have seen the example but I didn't > > think > > an example was authorative. Can I trust this example and/or your > > statement > > to be authorative? > > I've worked on at least four commercial implementations and this is > the way it is implemented in all of them. OK, thanks. This will cut the size of the router LSA significantly when you have many unnumbered interfaces. Also a lot of extra processing scanning for "routes to self" from neighbors will go away. > > > > Can I have your list of RFC 2328 inaccuracies? > > No - since it is an E-mail folder :^) You can scan the RFC errata. > > http://www.rfc-editor.org/errata.php Searching for RFC 2328 only turns up one entry. Is that really all there is? Maybe I am searching the wrong way? Jocke > > Thanks, > Acee > > > > > Jocke > > > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee@redback.com] > >> Sent: den 6 januari 2009 17:56 > >> To: Joakim Tjernlund > >> Cc: ospf@ietf.org > >> Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > >> > >> Hi Joakim, > >> While it certainly isn't described very well, the intent is that the > >> second router link is omitted for unnumbered links. If you look at > >> the example for RT3's backbone area router LSA on page 134, you'll > >> note the omission. > >> > >> ; RT3's router-LSA for the backbone > >> > >> LS age = 0 ;always true on origination > >> Options = (E-bit) ; > >> LS type = 1 ;indicates router-LSA > >> Link State ID = 192.1.1.3 ;RT3's router ID > >> Advertising Router = 192.1.1.3 ;RT3's router ID > >> bit E = 0 ;not an AS boundary router > >> bit B = 1 ;area border router > >> #links = 1 > >> Link ID = 18.10.0.6 ;Neighbor's Router ID > >> Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link > >> Type = 1 ;connects to router > >> # TOS metrics = 0 > >> metric = 8 > >> > >> I'll keep this in my list of RFC 2328 inaccuracies. > >> > >> Thanks, > >> Acee > >> > >> > >> On Jan 6, 2009, at 11:18 AM, Joakim Tjernlund wrote: > >> > >>> In RFC 2328, Chap 12.4.1.1, reads: > >>> 12.4.1.1. Describing point-to-point interfaces > >>> > >>> For point-to-point interfaces, one or more link > >>> descriptions are added to the router-LSA as follows: > >>> > >>> o If the neighboring router is fully adjacent, > >>> add a > >>> Type 1 link (point-to-point). The Link ID > >>> should be > >>> set to the Router ID of the neighboring router. > >>> For > >>> numbered point-to-point networks, the Link Data > >>> should specify the IP interface address. For > >>> unnumbered point-to-point networks, the Link > >>> Data > >>> field should specify the interface's MIB-II > >>> [Ref8] > >>> ifIndex value. The cost should be set to the > >>> output > >>> cost of the point-to-point interface. > >>> > >>> o In addition, as long as the state of the > >>> interface > >>> is "Point-to-Point" (and regardless of the > >>> neighboring router state), a Type 3 link (stub > >>> network) should be added. There are two forms > >>> that > >>> this stub link can take: > >>> > >>> Option 1 > >>> Assuming that the neighboring router's IP > >>> address is known, set the Link ID of the > >>> Type 3 > >>> link to the neighbor's IP address, the Link > >>> Data > >>> to the mask 0xffffffff (indicating a host > >>> route), and the cost to the interface's > >>> configured output cost.[15] > >>> > >>> Option 2 > >>> If a subnet has been assigned to the > >>> point-to- > >>> point link, set the Link ID of the Type 3 > >>> link > >>> to the subnet's IP address, the Link Data > >>> to the > >>> subnet's mask, and the cost to the > >>> interface's > >>> configured output cost.[16] > >>> > >>> I have a hard time figuring out what to do with Option 1 and Option > >>> 2 for unnumbered > >>> PtoP interfaces. I don't think either of them applies to an > >>> unnumbered link so > >>> I wonder if one should omit both Options? > >>> However 12.4.1.1 starts with: > >>> For point-to-point interfaces, one or more link > >>> descriptions are added to the router-LSA as follows > >>> > >>> which could be read as there must always be one or more items and > >>> as the first > >>> item needs to have a fully adjacent router you could end up with > >>> zero items in the LSA for > >>> a PtoP interface. > >>> So what should one do? > >>> > >>> 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 mayalily@133sh.com Tue Jan 6 13:35:20 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46413A6817 for ; Tue, 6 Jan 2009 13:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.02 X-Spam-Level: X-Spam-Status: No, score=-12.02 tagged_above=-999 required=5 tests=[AWL=7.523, BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 pa-Shz9l5+Dg for ; Tue, 6 Jan 2009 13:35:20 -0800 (PST) Received: from 3bd.com (unknown [92.112.202.114]) by core3.amsl.com (Postfix) with SMTP id C448C3A6452 for ; Tue, 6 Jan 2009 13:35:18 -0800 (PST) To: Subject: Re: Order status 56293 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106213518.C448C3A6452@core3.amsl.com> Date: Tue, 6 Jan 2009 13:35:18 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 45386
From ospf-bounces@ietf.org Tue Jan 6 15:35:17 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 AC7A93A6B0A; Tue, 6 Jan 2009 15:35:17 -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 074253A6B0A for ; Tue, 6 Jan 2009 15:35: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 fe3kOBGSKyLC for ; Tue, 6 Jan 2009 15:35:15 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id B78B83A6851 for ; Tue, 6 Jan 2009 15:35:12 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSWPqlY9cpCtvojSm6ulm60VemNUrKON2@postini.com; Tue, 06 Jan 2009 15:35:03 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.336.0; Tue, 6 Jan 2009 15:34:37 -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); Tue, 6 Jan 2009 15:34:37 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 15:34:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 15:34:36 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n06NYaM72318; Tue, 6 Jan 2009 15:34:36 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Joakim Tjernlund In-Reply-To: <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 6 Jan 2009 16:34:35 -0700 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Jan 2009 23:34:36.0820 (UTC) FILETIME=[563EED40:01C97057] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org On Jan 6, 2009, at 2:19 PM, Joakim Tjernlund wrote: >> >> The footnote is sort of bogus on three counts. First of all, a = >> router >> *must* have an address somewhere, or it has nothing to put in the IP >> source address field, can't be managed, and is an incredibly = >> expensive >> door stop. So that bit is redundant. > > Obviously an IP address is needed, the key part is that the IP address > should be announced as an host route in the router LSA. > >> Secondly, there is no explicit >> mechanism in the spec for advertising that host route, unless this >> sentence is intended to be normative (in which case the "will" should >> be a "SHALL".) > > What mechanism do you need? It is an impl. detail how you specify > that IP address, if you need one. Will vs. shall is perhaps an = > error, I can't > say, but I don't think the language in Option 1 or Option 2 is any = > stronger. > >> Thirdly, if implementations were to actually follow >> the other section you mention and do option 1, advertising that host >> route is unnecessary because all of the OSPF neighbors will know the >> address and advertise it themselves (roundabout, as mentioned = >> earlier, >> but it works.) And that footnote is much narrower than the case we >> are talking about, which is that of *any* unnumbered interface, >> regardless of whether there are other numbered interfaces or not. > > You only have do this iff you just have unnumbered interfaces, no need > to add an extra host route if you already announce one. I think we've gone in circles here. If I understood your original posting, you were asking about the = meaning/value of the options listed as part of 12.4.1.1. The reason = that they are there is to ensure reachability to the remote router = itself, if it implements exactly what the spec says to do. If the = local router doesn't do Option 1, and the remote router only does = exactly what the spec says to do, you will not be able to route to the = remote router because nobody will announce reachability to its address. One can look at the spec and say, "of course I should announce host = routes for addresses I think the world might be interested in", and it = will work, but the spec never actually says to do that, *except* in = the case of a router with no numbered interfaces at all (and burying = it in a footnote at the very end of the spec is not a terribly good = thing even in that case.) So a na=EFve implementor will still have a functional, reachable, = manageable network if he implements Option 1 and doesn't advertise any = host routes otherwise. This is why Option 1 exists, and why it is = normative. If my box is neighbor to the the na=EFve implementor's box, = and I don't do Option 1, and he doesn't have his loopback address or = some other address outside of OSPF in a host route (perfectly in- = spec), his box is going to be unreachable for management purposes. Maybe I'm missing something here? > > >> >>> >>> >>> An related question: what to do with an interface that is UP but not >>> RUNNING? >> >> Given that these terms are not well-defined, it's not possible to >> answer in a normative way. Even in a non-normative, casual way, it's >> not clear to me what the actual difference is. If the link does not >> pass packets, for whatever reason, OSPF will not come up, and traffic >> will not be passed to the nonfunctional link. Whether that interface >> address is advertised by the offending router is an implementation >> decision, as it has no functional use other than as a management >> address. For that matter, it is then immaterial as to whether the >> interface is "up" in any way or not, since there's no traffic going = >> to >> that interface anyhow. One could choose to advertise *all* interface >> addresses as host routes whether the interface is up or not, in case >> anybody is sending packets to those addresses from afar. But this is >> usually done with loopback addresses, which become the "router >> address" for management purposes and are independent of any physical >> hardware. > > The IP address on that link is still reachable through other = > interfaces. If you > have a connection to the router using its IP address, you can still = > use it > even if the interface isn't RUNNING(i.e someone pulled the cable for = > that interface). > So instead of removing the whole interface and its subnet from the = > OSPF domain, one > should change the router LSA to announce a host route with that = > interface's IP address. I guess I still don't understand the distinction between UP and = RUNNING, but that's OK. The point is (and I think we're in violent = agreement) that if you want a router address to be reachable, it = either has to be announced as a host route or as part of a subnet = route. If the interface isn't passing traffic, announcing a subnet = route would be an exceedingly poor idea, so the host route is the way = to go. The spec is properly (IMHO) silent on when to send host routes = in this case, as it is purely an implementation decision and is not = subject to standardization. > > That way you can have an router with one Ethernet interface that is = > always reachable > over any other(unnumbered) interface. This is essentially independent of unnumbered interfaces. The = requirement for unnumbered interfaces is only that the source address = in OSPF packets is reachable, so that the local router can send = packets back to it. The remote router can advertise host routes for = any or all of its interface addresses if it wishes to, but in fact it = doesn't need to advertise *any* host route for this to work, as the = neighbor (by option 1) is required to advertise a host route on its = behalf, which will draw traffic to the unnumbered interface. If a router wishes to advertise host routes for interfaces so that = management traffic may use them without worrying about the associated = interface state, it can. Note that this is no different than having = functioning router interfaces that are not actually part of the OSPF = domain (which is quite common.) --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 6 17:41:42 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 452903A689E; Tue, 6 Jan 2009 17:41:42 -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 965483A689E for ; Tue, 6 Jan 2009 17:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 M9Y-avrz2D0O for ; Tue, 6 Jan 2009 17:41:37 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 8D14C3A6452 for ; Tue, 6 Jan 2009 17:41:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E2103417473; Tue, 6 Jan 2009 17:41:24 -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 24231-06; Tue, 6 Jan 2009 17:41:24 -0800 (PST) Received: from [IPv6???1] (lxlogin-4-300.redback.com [155.53.12.219]) by prattle.redback.com (Postfix) with ESMTP id 30ECB417474; Tue, 6 Jan 2009 17:41:23 -0800 (PST) In-Reply-To: <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <99473301-1D56-4C49-AFA9-F7663017379C@redback.com> From: Acee Lindem Date: Tue, 6 Jan 2009 20:41:23 -0500 To: Dave Katz X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 Dave, Joakim, The intent of the protocol is to not advertise stub links in router LSAs for unnumbered links. If one wishes to advertise the local address an unnumbered link is using, the interface should be configured as an OSPF interface. Unfortunately, RFC 2328 section 12.4.1.1 doesn't state this explicitly. Although I wasn't involved in the generation or review of RFC 2328, John Moy's public domain implementation (available at www.ospf.org) confirms this behavior and is consistent with most implementations - though possibly not all implementations. Thanks, Acee On Jan 6, 2009, at 1:46 PM, Dave Katz wrote: > The idea of Option 1 is to provide connectivity to the remote > router itself. The remote router has an address, and it is known > to the local router as soon as the first Hello is received. So by > definition it is always possible to do (since the remote router's > address must be known in order to have an adjacency in the first > place.) > > One could claim that it would make more sense for a router to > announce its *own* address in a link, and in fact some > implementations do so gratuitously for safety's sake. Or a > loopback interface (with an independent address) is included in the > OSPF configuration to achieve the same thing. But without either > Option 1 or one of the hacks, it may not be possible to address the > router itself for management purposes. > > So I would not suggest to omit the second link; the inaccuracy is > in the example instead. > > --Dave > > > > On Jan 6, 2009, at 11:31 AM, Joakim Tjernlund wrote: > >> Hi Acee >> >> Thanks for your quick answer. I have seen the example but I didn't >> think >> an example was authorative. Can I trust this example and/or your >> statement >> to be authorative? >> Can I have your list of RFC 2328 inaccuracies? >> >> Jocke >> >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee@redback.com] >>> Sent: den 6 januari 2009 17:56 >>> To: Joakim Tjernlund >>> Cc: ospf@ietf.org >>> Subject: Re: [OSPF] Unnumbered PtoP router LSA question. >>> >>> Hi Joakim, >>> While it certainly isn't described very well, the intent is that the >>> second router link is omitted for unnumbered links. If you look at >>> the example for RT3's backbone area router LSA on page 134, you'll >>> note the omission. >>> >>> ; RT3's router-LSA for the backbone >>> >>> LS age = 0 ;always true on origination >>> Options = (E-bit) ; >>> LS type = 1 ;indicates router-LSA >>> Link State ID = 192.1.1.3 ;RT3's router ID >>> Advertising Router = 192.1.1.3 ;RT3's router ID >>> bit E = 0 ;not an AS boundary router >>> bit B = 1 ;area border router >>> #links = 1 >>> Link ID = 18.10.0.6 ;Neighbor's Router ID >>> Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link >>> Type = 1 ;connects to router >>> # TOS metrics = 0 >>> metric = 8 >>> >>> I'll keep this in my list of RFC 2328 inaccuracies. >>> >>> Thanks, >>> Acee >>> >>> >>> On Jan 6, 2009, at 11:18 AM, Joakim Tjernlund wrote: >>> >>>> In RFC 2328, Chap 12.4.1.1, reads: >>>> 12.4.1.1. Describing point-to-point interfaces >>>> >>>> For point-to-point interfaces, one or more link >>>> descriptions are added to the router-LSA as follows: >>>> >>>> o If the neighboring router is fully adjacent, >>>> add a >>>> Type 1 link (point-to-point). The Link ID >>>> should be >>>> set to the Router ID of the neighboring router. >>>> For >>>> numbered point-to-point networks, the Link Data >>>> should specify the IP interface address. For >>>> unnumbered point-to-point networks, the Link >>>> Data >>>> field should specify the interface's MIB-II >>>> [Ref8] >>>> ifIndex value. The cost should be set to the >>>> output >>>> cost of the point-to-point interface. >>>> >>>> o In addition, as long as the state of the >>>> interface >>>> is "Point-to-Point" (and regardless of the >>>> neighboring router state), a Type 3 link (stub >>>> network) should be added. There are two forms >>>> that >>>> this stub link can take: >>>> >>>> Option 1 >>>> Assuming that the neighboring router's IP >>>> address is known, set the Link ID of the >>>> Type 3 >>>> link to the neighbor's IP address, the Link >>>> Data >>>> to the mask 0xffffffff (indicating a host >>>> route), and the cost to the interface's >>>> configured output cost.[15] >>>> >>>> Option 2 >>>> If a subnet has been assigned to the >>>> point-to- >>>> point link, set the Link ID of the Type 3 >>>> link >>>> to the subnet's IP address, the Link Data >>>> to the >>>> subnet's mask, and the cost to the >>>> interface's >>>> configured output cost.[16] >>>> >>>> I have a hard time figuring out what to do with Option 1 and Option >>>> 2 for unnumbered >>>> PtoP interfaces. I don't think either of them applies to an >>>> unnumbered link so >>>> I wonder if one should omit both Options? >>>> However 12.4.1.1 starts with: >>>> For point-to-point interfaces, one or more link >>>> descriptions are added to the router-LSA as follows >>>> >>>> which could be read as there must always be one or more items and >>>> as the first >>>> item needs to have a fully adjacent router you could end up with >>>> zero items in the LSA for >>>> a PtoP interface. >>>> So what should one do? >>>> >>>> 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 >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 6 20:33:35 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 D32BF28C0FF; Tue, 6 Jan 2009 20:33:35 -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 5D6C53A69A7 for ; Tue, 6 Jan 2009 20:33:35 -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 pSTPKEWiwEKz for ; Tue, 6 Jan 2009 20:33:33 -0800 (PST) Received: from chip3og54.obsmtp.com (chip3og54.obsmtp.com [64.18.14.173]) by core3.amsl.com (Postfix) with ESMTP id 14B8C28C119 for ; Tue, 6 Jan 2009 20:33:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob54.postini.com ([64.18.6.12]) with SMTP ID DSNKSWQwfPOcQPrrIQQhmGhcv9qQoPgKCrB6@postini.com; Tue, 06 Jan 2009 20:33:21 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.336.0; Tue, 6 Jan 2009 20:30:33 -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, 6 Jan 2009 20:30:32 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 20:30:32 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 20:30:31 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n074UVM93732; Tue, 6 Jan 2009 20:30:31 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <56D50EB7-D482-45D5-8CB4-EC53D4F52FCC@juniper.net> From: Dave Katz To: Acee Lindem In-Reply-To: <99473301-1D56-4C49-AFA9-F7663017379C@redback.com> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 6 Jan 2009 21:30:29 -0700 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <99473301-1D56-4C49-AFA9-F7663017379C@redback.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 07 Jan 2009 04:30:31.0944 (UTC) FILETIME=[AD1FD880:01C97080] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 Well, *somebody* needs to advertise the address used as the source address for OSPF on unnumbered links, or the protocol will fail. The spec specifically says that the receiver of said packets is supposed to advertise that address. The spec does *not* say that the owner of that address should advertise it, as stupid as that may seem. Speaking of intent is all well and good, but the spec has been out there for about 20 years now and it says something else. John Moy's implementation is not the spec. In reality, implementors seem to end up doing the right thing anyhow. (I still get grief for advertising the loopback address by default in our implementation, 11 years on, as that's not in the spec either.) But the spec, as written, works. Simply ignoring Option 1 for unnumbered links *breaks the spec*. Unless the spec is changed to specifically require that the address used as the source on unnumbered links is advertised in *some* LSA by the owner of said address, we cannot say that the clause as written is in error. --Dave On Jan 6, 2009, at 6:41 PM, Acee Lindem wrote: > Hi Dave, Joakim, > The intent of the protocol is to not advertise stub links in router > LSAs for unnumbered links. If one wishes to advertise the local > address an unnumbered link is using, the interface should be > configured as an OSPF interface. Unfortunately, RFC 2328 section > 12.4.1.1 doesn't state this explicitly. Although I wasn't involved > in the generation or review of RFC 2328, John Moy's public domain > implementation (available at www.ospf.org) confirms this behavior > and is consistent with most implementations - though possibly not > all implementations. > Thanks, > Acee > On Jan 6, 2009, at 1:46 PM, Dave Katz wrote: > >> The idea of Option 1 is to provide connectivity to the remote >> router itself. The remote router has an address, and it is known >> to the local router as soon as the first Hello is received. So by >> definition it is always possible to do (since the remote router's >> address must be known in order to have an adjacency in the first >> place.) >> >> One could claim that it would make more sense for a router to >> announce its *own* address in a link, and in fact some >> implementations do so gratuitously for safety's sake. Or a >> loopback interface (with an independent address) is included in the >> OSPF configuration to achieve the same thing. But without either >> Option 1 or one of the hacks, it may not be possible to address the >> router itself for management purposes. >> >> So I would not suggest to omit the second link; the inaccuracy is >> in the example instead. >> >> --Dave >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 6 21:55:25 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 8A34F3A69F8; Tue, 6 Jan 2009 21:55:25 -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 B933C3A69F8 for ; Tue, 6 Jan 2009 21:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 XMxwbe-69KwJ for ; Tue, 6 Jan 2009 21:55:22 -0800 (PST) Received: from securemail.onebox.com (outgoing3.onebox.com [69.25.242.13]) by core3.amsl.com (Postfix) with ESMTP id 4FB6B3A69E4 for ; Tue, 6 Jan 2009 21:55:22 -0800 (PST) Received: from homexpc (unverified [24.7.51.248]) by securemail.onebox.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Wed, 7 Jan 2009 00:55:04 -0500 From: "Sean Andersen" To: "'Dave Katz'" , "'Acee Lindem'" References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se><002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se><9D385273-7F28-4C06-810E-47C28822F506@juniper.net><99473301-1D56-4C49-AFA9-F7663017379C@redback.com> <56D50EB7-D482-45D5-8CB4-EC53D4F52FCC@juniper.net> Date: Tue, 6 Jan 2009 21:55:04 -0800 Message-ID: <27F96592D0A3424A80821FB7F7C781CE@homexpc> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <56D50EB7-D482-45D5-8CB4-EC53D4F52FCC@juniper.net> Thread-Index: AclwgRkKc8Mj32BhRbOk3VYoqOtFxAACqyQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 There was a discussion about virtual links that kind of relates to this discussion in a way. Although a virtual link through a stub area is not applicable. I sent an email on that in 2003 and just found it in one of the archives (link below)...hope it helps even though it may not be very closely related to this discussion: http://archives.neohapsis.com/archives/microsoft/various/ospf/2003-q1/0184.h tml Sean (Farshad) -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Dave Katz Sent: Tuesday, January 06, 2009 8:30 PM To: Acee Lindem Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA question. Well, *somebody* needs to advertise the address used as the source address for OSPF on unnumbered links, or the protocol will fail. The spec specifically says that the receiver of said packets is supposed to advertise that address. The spec does *not* say that the owner of that address should advertise it, as stupid as that may seem. Speaking of intent is all well and good, but the spec has been out there for about 20 years now and it says something else. John Moy's implementation is not the spec. In reality, implementors seem to end up doing the right thing anyhow. (I still get grief for advertising the loopback address by default in our implementation, 11 years on, as that's not in the spec either.) But the spec, as written, works. Simply ignoring Option 1 for unnumbered links *breaks the spec*. Unless the spec is changed to specifically require that the address used as the source on unnumbered links is advertised in *some* LSA by the owner of said address, we cannot say that the clause as written is in error. --Dave On Jan 6, 2009, at 6:41 PM, Acee Lindem wrote: > Hi Dave, Joakim, > The intent of the protocol is to not advertise stub links in router > LSAs for unnumbered links. If one wishes to advertise the local > address an unnumbered link is using, the interface should be > configured as an OSPF interface. Unfortunately, RFC 2328 section > 12.4.1.1 doesn't state this explicitly. Although I wasn't involved > in the generation or review of RFC 2328, John Moy's public domain > implementation (available at www.ospf.org) confirms this behavior > and is consistent with most implementations - though possibly not > all implementations. > Thanks, > Acee > On Jan 6, 2009, at 1:46 PM, Dave Katz wrote: > >> The idea of Option 1 is to provide connectivity to the remote >> router itself. The remote router has an address, and it is known >> to the local router as soon as the first Hello is received. So by >> definition it is always possible to do (since the remote router's >> address must be known in order to have an adjacency in the first >> place.) >> >> One could claim that it would make more sense for a router to >> announce its *own* address in a link, and in fact some >> implementations do so gratuitously for safety's sake. Or a >> loopback interface (with an independent address) is included in the >> OSPF configuration to achieve the same thing. But without either >> Option 1 or one of the hacks, it may not be possible to address the >> router itself for management purposes. >> >> So I would not suggest to omit the second link; the inaccuracy is >> in the example instead. >> >> --Dave >> _______________________________________________ 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 Wed Jan 7 06:19:07 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 58BF628C1A7; Wed, 7 Jan 2009 06:19:07 -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 500F928C1A7 for ; Wed, 7 Jan 2009 06:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396] 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 2oO-OktwOsRA for ; Wed, 7 Jan 2009 06:19:05 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id A6FB728C16D for ; Wed, 7 Jan 2009 06:19:03 -0800 (PST) Received: mail.transmode.se 192.168.46.15 from 192.168.1.15 192.168.1.15 via HTTP with MS-WebStorage 6.0.6249 Received: from gentoo-jocke by mail.transmode.se; 07 Jan 2009 15:18:49 +0100 From: Joakim Tjernlund To: Dave Katz In-Reply-To: References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> Organization: Transmode AB Date: Wed, 07 Jan 2009 15:18:49 +0100 Message-Id: <1231337929.21348.177.camel@gentoo-jocke.transmode.se> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA question. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joakim.tjernlund@transmode.se List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org On Tue, 2009-01-06 at 16:34 -0700, Dave Katz wrote: > On Jan 6, 2009, at 2:19 PM, Joakim Tjernlund wrote: > = > >> > >> The footnote is sort of bogus on three counts. First of all, a = > >> router > >> *must* have an address somewhere, or it has nothing to put in the IP > >> source address field, can't be managed, and is an incredibly = > >> expensive > >> door stop. So that bit is redundant. > > > > Obviously an IP address is needed, the key part is that the IP address > > should be announced as an host route in the router LSA. > > > >> Secondly, there is no explicit > >> mechanism in the spec for advertising that host route, unless this > >> sentence is intended to be normative (in which case the "will" should > >> be a "SHALL".) > > > > What mechanism do you need? It is an impl. detail how you specify > > that IP address, if you need one. Will vs. shall is perhaps an = > > error, I can't > > say, but I don't think the language in Option 1 or Option 2 is any = > > stronger. > > > >> Thirdly, if implementations were to actually follow > >> the other section you mention and do option 1, advertising that host > >> route is unnecessary because all of the OSPF neighbors will know the > >> address and advertise it themselves (roundabout, as mentioned = > >> earlier, > >> but it works.) And that footnote is much narrower than the case we > >> are talking about, which is that of *any* unnumbered interface, > >> regardless of whether there are other numbered interfaces or not. > > > > You only have do this iff you just have unnumbered interfaces, no need > > to add an extra host route if you already announce one. > = > I think we've gone in circles here. > = > If I understood your original posting, you were asking about the = > meaning/value of the options listed as part of 12.4.1.1. The reason = > that they are there is to ensure reachability to the remote router = > itself, if it implements exactly what the spec says to do. If the = > local router doesn't do Option 1, and the remote router only does = > exactly what the spec says to do, you will not be able to route to the = > remote router because nobody will announce reachability to its address. > = > One can look at the spec and say, "of course I should announce host = > routes for addresses I think the world might be interested in", and it = > will work, but the spec never actually says to do that, *except* in = > the case of a router with no numbered interfaces at all (and burying = > it in a footnote at the very end of the spec is not a terribly good = > thing even in that case.) > = > So a na=EFve implementor will still have a functional, reachable, = > manageable network if he implements Option 1 and doesn't advertise any = > host routes otherwise. This is why Option 1 exists, and why it is = > normative. If my box is neighbor to the the na=EFve implementor's box, = > and I don't do Option 1, and he doesn't have his loopback address or = > some other address outside of OSPF in a host route (perfectly in- = > spec), his box is going to be unreachable for management purposes. I would not say that it is "perfectly in spec" as the spec actually mentions this case explicitly in that footnote. I guess that the spec assumes that it is very uncommon to just have unnumbered links is the domain and that is perhaps why it is in a footnote. Also I can can't find a reference in the spec that states that the purpose of Option 1 is reachability, in [15] one can read: = [15]This is the way RFC 1583 specified point-to-point representation. It has three advantages: a) it does not require allocating a subnet to the point-to-point link, b) it tends to bias the routing so that packets destined for the point-to-point interface will actually be received over the interface (which is useful for diagnostic purposes) and c) it allows network bootstrapping of a neighbor, without requiring that the bootstrap program contain an OSPF implementation. Further, looking into RFC 1583 one can see that Option 1 isn't used for unnumbered links. Also, there would be no need for footnote [2] if Option 1 is required so why have in the first place? Actully, the only thing that might suggest that Option 1 should be used in 2328 is the text i Option 1 and that text is a bit "fuzzy". Everything else suggests that Option 1 should not be used(in my reading) > = > Maybe I'm missing something here? > = > > > > > >> > >>> > >>> > >>> An related question: what to do with an interface that is UP but not > >>> RUNNING? > >> > >> Given that these terms are not well-defined, it's not possible to > >> answer in a normative way. Even in a non-normative, casual way, it's > >> not clear to me what the actual difference is. If the link does not > >> pass packets, for whatever reason, OSPF will not come up, and traffic > >> will not be passed to the nonfunctional link. Whether that interface > >> address is advertised by the offending router is an implementation > >> decision, as it has no functional use other than as a management > >> address. For that matter, it is then immaterial as to whether the > >> interface is "up" in any way or not, since there's no traffic going = > >> to > >> that interface anyhow. One could choose to advertise *all* interface > >> addresses as host routes whether the interface is up or not, in case > >> anybody is sending packets to those addresses from afar. But this is > >> usually done with loopback addresses, which become the "router > >> address" for management purposes and are independent of any physical > >> hardware. > > > > The IP address on that link is still reachable through other = > > interfaces. If you > > have a connection to the router using its IP address, you can still = > > use it > > even if the interface isn't RUNNING(i.e someone pulled the cable for = > > that interface). > > So instead of removing the whole interface and its subnet from the = > > OSPF domain, one > > should change the router LSA to announce a host route with that = > > interface's IP address. > = > I guess I still don't understand the distinction between UP and = > RUNNING, but that's OK. Sorry, I should have explained this better. I refering to the status of the interface as returned by ifconfig: # > ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:06:9C:00:20:02 = inet addr:10.0.1.1 Bcast:10.0.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 If I disconnect the ethernet cable, the RUNNING status goes away since the interface cannot pass traffic on the ethernet, but the interface is still UP. What does Juniper do in this case for an interface that is part of a OSPF area? I really like to find out how other routers handle this case. = = > The point is (and I think we're in violent = > agreement) that if you want a router address to be reachable, it = > either has to be announced as a host route or as part of a subnet = > route. If the interface isn't passing traffic, announcing a subnet = > route would be an exceedingly poor idea, so the host route is the way = > to go. The spec is properly (IMHO) silent on when to send host routes = > in this case, as it is purely an implementation decision and is not = > subject to standardization. I think this is implicit in the spec. One can ask OSPF to announce some subnets and all matching interfaces are then announced, if you pull the cable, the IP address still matches and is reachable so it should still be announced as a host route. = Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 7 09:30:46 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 1731428C132; Wed, 7 Jan 2009 09:30:46 -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 4B2FC28C132 for ; Wed, 7 Jan 2009 09:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_47=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 MSZzAJfv8wYD for ; Wed, 7 Jan 2009 09:30:44 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 0081E28C119 for ; Wed, 7 Jan 2009 09:30:42 -0800 (PST) Received: mail.transmode.se 192.168.46.15 from 192.168.1.15 192.168.1.15 via HTTP with MS-WebStorage 6.0.6249 Received: from gentoo-jocke by mail.transmode.se; 07 Jan 2009 18:30:25 +0100 From: Joakim Tjernlund To: Dave Katz In-Reply-To: <56D50EB7-D482-45D5-8CB4-EC53D4F52FCC@juniper.net> References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <99473301-1D56-4C49-AFA9-F7663017379C@redback.com> <56D50EB7-D482-45D5-8CB4-EC53D4F52FCC@juniper.net> Organization: Transmode AB Date: Wed, 07 Jan 2009 18:30:24 +0100 Message-Id: <1231349424.21348.244.camel@gentoo-jocke.transmode.se> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA question. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joakim.tjernlund@transmode.se 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 On Tue, 2009-01-06 at 21:30 -0700, Dave Katz wrote: > Well, *somebody* needs to advertise the address used as the source > address for OSPF on unnumbered links, or the protocol will fail. The > spec specifically says that the receiver of said packets is supposed > to advertise that address. The spec does *not* say that the owner of > that address should advertise it, as stupid as that may seem. Does it really have to be the source address used by the unnumbered links? Isn't it enough to add any IP address used on the router? So if you have at least one numbered interface in the area, you are good. If not, you will add a host route as footnote 2 says, usally done with a loopback or dummy interface. > > Speaking of intent is all well and good, but the spec has been out > there for about 20 years now and it says something else. John Moy's > implementation is not the spec. > > In reality, implementors seem to end up doing the right thing anyhow. Which ones(besides Juniper)? According to Acee at least 4 commercial vendors does not. > > (I still get grief for advertising the loopback address by default in > our implementation, 11 years on, as that's not in the spec either.) > But the spec, as written, works. Simply ignoring Option 1 for > unnumbered links *breaks the spec*. Unless the spec is changed to > specifically require that the address used as the source on unnumbered > links is advertised in *some* LSA by the owner of said address, we > cannot say that the clause as written is in error. The spec is fuzzy, for instance it says "a Type 3 link (stub network) should be added" "Should" isn't very strict and the text in Option 1 is also a bit fuzzy so I would not say that omitting Option 1 breaks the spec even in its current form. That said, I really think an official statement from IETF is needed. Otherwise this issue will haunt OSPF for years to come. Jocke > > --Dave > > > On Jan 6, 2009, at 6:41 PM, Acee Lindem wrote: > > > Hi Dave, Joakim, > > The intent of the protocol is to not advertise stub links in router > > LSAs for unnumbered links. If one wishes to advertise the local > > address an unnumbered link is using, the interface should be > > configured as an OSPF interface. Unfortunately, RFC 2328 section > > 12.4.1.1 doesn't state this explicitly. Although I wasn't involved > > in the generation or review of RFC 2328, John Moy's public domain > > implementation (available at www.ospf.org) confirms this behavior > > and is consistent with most implementations - though possibly not > > all implementations. > > Thanks, > > Acee > > On Jan 6, 2009, at 1:46 PM, Dave Katz wrote: > > > >> The idea of Option 1 is to provide connectivity to the remote > >> router itself. The remote router has an address, and it is known > >> to the local router as soon as the first Hello is received. So by > >> definition it is always possible to do (since the remote router's > >> address must be known in order to have an adjacency in the first > >> place.) > >> > >> One could claim that it would make more sense for a router to > >> announce its *own* address in a link, and in fact some > >> implementations do so gratuitously for safety's sake. Or a > >> loopback interface (with an independent address) is included in the > >> OSPF configuration to achieve the same thing. But without either > >> Option 1 or one of the hacks, it may not be possible to address the > >> router itself for management purposes. > >> > >> So I would not suggest to omit the second link; the inaccuracy is > >> in the example instead. > >> > >> --Dave > >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From mrblair@allelys.co.uk Wed Jan 7 09:43:15 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123923A6A07 for ; Wed, 7 Jan 2009 09:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.113 X-Spam-Level: X-Spam-Status: No, score=-12.113 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 AIccAjJAzKw0 for ; Wed, 7 Jan 2009 09:43:14 -0800 (PST) Received: from ageun.com (unknown [190.156.166.135]) by core3.amsl.com (Postfix) with SMTP id 097FC3A6802 for ; Wed, 7 Jan 2009 09:43:12 -0800 (PST) To: Subject: Mail delivery failed: returning message to sender From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107174313.097FC3A6802@core3.amsl.com> Date: Wed, 7 Jan 2009 09:43:12 -0800 (PST) About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

C2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 From jorusn@agrupaciomutua.es Wed Jan 7 15:09:26 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEABC3A6A0D for ; Wed, 7 Jan 2009 15:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.507 X-Spam-Level: X-Spam-Status: No, score=-31.507 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 aZZO8Xk-oJ7p for ; Wed, 7 Jan 2009 15:09:25 -0800 (PST) Received: from alexmannjobs.com (unknown [190.244.20.55]) by core3.amsl.com (Postfix) with SMTP id C99F63A67FB for ; Wed, 7 Jan 2009 15:09:24 -0800 (PST) To: Subject: Can't find you, darling From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107230924.C99F63A67FB@core3.amsl.com> Date: Wed, 7 Jan 2009 15:09:24 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ospf-bounces@ietf.org Wed Jan 7 20:23:06 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 161403A6916; Wed, 7 Jan 2009 20:23:06 -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 B177F3A6916 for ; Wed, 7 Jan 2009 20:23:04 -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_42=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 MUNUp6ewj9CS for ; Wed, 7 Jan 2009 20:23:02 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 403843A681F for ; Wed, 7 Jan 2009 20:23:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=H1UVTR+eu+HtQfVy8Brk/1CBO7jQSfTP2Hiun1uDI4oTH4HCf73R1Pb0tSHVHyP5; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.221.94] by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LKmPr-00016y-Cs; Wed, 07 Jan 2009 23:22:45 -0500 Message-ID: <49658039.1090204@earthlink.net> Date: Wed, 07 Jan 2009 20:25:29 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: joakim.tjernlund@transmode.se References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> In-Reply-To: <1231337929.21348.177.camel@gentoo-jocke.transmode.se> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4781111e4c6ff0530fa064879b1b1dfa83a5d8d0b3e7d109fc1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.94 Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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: quoted-printable Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Joakim Tjernlund wrote: >On Tue, 2009-01-06 at 16:34 -0700, Dave Katz wrote: > >>On Jan 6, 2009, at 2:19 PM, Joakim Tjernlund wrote: >> >> >>>>The footnote is sort of bogus on three counts. First of all, a = >>>>router >>>>*must* have an address somewhere, or it has nothing to put in the IP >>>>source address field, can't be managed, and is an incredibly = >>>>expensive >>>>door stop. So that bit is redundant. >>>> >>>Obviously an IP address is needed, the key part is that the IP address >>>should be announced as an host route in the router LSA. >>> >>> >>>>Secondly, there is no explicit >>>>mechanism in the spec for advertising that host route, unless this >>>>sentence is intended to be normative (in which case the "will" should >>>>be a "SHALL".) >>>> >>>What mechanism do you need? It is an impl. detail how you specify >>>that IP address, if you need one. Will vs. shall is perhaps an = >>>error, I can't >>>say, but I don't think the language in Option 1 or Option 2 is any = >>>stronger. >>> >>> >>>>Thirdly, if implementations were to actually follow >>>>the other section you mention and do option 1, advertising that host >>>>route is unnecessary because all of the OSPF neighbors will know the >>>>address and advertise it themselves (roundabout, as mentioned = >>>>earlier, >>>>but it works.) And that footnote is much narrower than the case we >>>>are talking about, which is that of *any* unnumbered interface, >>>>regardless of whether there are other numbered interfaces or not. >>>> >>>You only have do this iff you just have unnumbered interfaces, no need >>>to add an extra host route if you already announce one. >>> >>I think we've gone in circles here. >> >>If I understood your original posting, you were asking about the = >>meaning/value of the options listed as part of 12.4.1.1. The reason = >>that they are there is to ensure reachability to the remote router = >>itself, if it implements exactly what the spec says to do. If the = >>local router doesn't do Option 1, and the remote router only does = >>exactly what the spec says to do, you will not be able to route to the = >>remote router because nobody will announce reachability to its address. >> >>One can look at the spec and say, "of course I should announce host = >>routes for addresses I think the world might be interested in", and it = >>will work, but the spec never actually says to do that, *except* in = >>the case of a router with no numbered interfaces at all (and burying = >>it in a footnote at the very end of the spec is not a terribly good = >>thing even in that case.) >> >>So a na=EFve implementor will still have a functional, reachable, = >>manageable network if he implements Option 1 and doesn't advertise any = >>host routes otherwise. This is why Option 1 exists, and why it is = >>normative. If my box is neighbor to the the na=EFve implementor's box, = >>and I don't do Option 1, and he doesn't have his loopback address or = >>some other address outside of OSPF in a host route (perfectly in- = >>spec), his box is going to be unreachable for management purposes. >> > >I would not say that it is "perfectly in spec" as the spec actually >mentions this case explicitly in that footnote. I guess that the spec >assumes that it is very uncommon to just have unnumbered links is the >domain and that is perhaps why it is in a footnote. > >Also I can can't find a reference in the spec that states that >the purpose of Option 1 is reachability, in [15] one can read: = >[15]This is the way RFC 1583 specified point-to-point > representation. It has three advantages: a) it does not require > allocating a subnet to the point-to-point link, b) it tends to bias > the routing so that packets destined for the point-to-point > interface will actually be received over the interface (which is > useful for diagnostic purposes) and c) it allows network > bootstrapping of a neighbor, without requiring that the bootstrap > program contain an OSPF implementation. > >Further, looking into RFC 1583 one can see that Option 1 isn't used for >unnumbered links. > >Also, there would be no need for footnote [2] if Option 1 is required >so why have in the first place? > >Actully, the only thing that might suggest that Option 1 should be >used in 2328 is the text i Option 1 and that text is a bit "fuzzy". >Everything else suggests that Option 1 should not be used(in my reading) > I have found this discussion interesting and educational. The above argument is very convincing, which I guess is why nobody is arguing against it. Based on the discussion, I think RFC 2328 should be clarified as follows to allow some flexibility while ensuring interoperability between different implementations (including most existing implementations). - Footnote [2] MUST be implemented, i.e., if all of the router's interfaces are point-to-point links, then the router's IP address MUST be advertised in the router-LSA as a host route. - For unnumbered point-to-point links, a Type 3 link (stub network) MAY be added to the router-LSA (Option 1), but is not required. Although adding such links may seem redundant, it has the benefit of ensuring that routes calculated to each router are *shortest* paths. Without adding the stub links, the calculated routing table will provide the shortest path to each network and host, but that need not result in the shortest path to a router that is not advertising its own IP address as a host route. For example, the last hop of the shortest path might be via an unnumbered point-to-point link, but the last hop of the calculated path might be via a numbered point-to-point link (which includes a stub link to the destination router). Let me know if I am mistaken. Richard = >>Maybe I'm missing something here? >> >> >>> >>>>> >>>>>An related question: what to do with an interface that is UP but not >>>>>RUNNING? >>>>> >>>>Given that these terms are not well-defined, it's not possible to >>>>answer in a normative way. Even in a non-normative, casual way, it's >>>>not clear to me what the actual difference is. If the link does not >>>>pass packets, for whatever reason, OSPF will not come up, and traffic >>>>will not be passed to the nonfunctional link. Whether that interface >>>>address is advertised by the offending router is an implementation >>>>decision, as it has no functional use other than as a management >>>>address. For that matter, it is then immaterial as to whether the >>>>interface is "up" in any way or not, since there's no traffic going = >>>>to >>>>that interface anyhow. One could choose to advertise *all* interface >>>>addresses as host routes whether the interface is up or not, in case >>>>anybody is sending packets to those addresses from afar. But this is >>>>usually done with loopback addresses, which become the "router >>>>address" for management purposes and are independent of any physical >>>>hardware. >>>> >>>The IP address on that link is still reachable through other = >>>interfaces. If you >>>have a connection to the router using its IP address, you can still = >>>use it >>>even if the interface isn't RUNNING(i.e someone pulled the cable for = >>>that interface). >>>So instead of removing the whole interface and its subnet from the = >>>OSPF domain, one >>>should change the router LSA to announce a host route with that = >>>interface's IP address. >>> >>I guess I still don't understand the distinction between UP and = >>RUNNING, but that's OK. >> > >Sorry, I should have explained this better. I refering to the >status of the interface as returned by ifconfig: ># > ifconfig eth0 >eth0 Link encap:Ethernet HWaddr 00:06:9C:00:20:02 = > inet addr:10.0.1.1 Bcast:10.0.255.255 Mask:255.255.0.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > >If I disconnect the ethernet cable, the RUNNING status goes away since >the interface cannot pass traffic on the ethernet, but the interface is >still UP. > >What does Juniper do in this case for an interface that is part >of a OSPF area? I really like to find out how other routers handle >this case. = > = > >>The point is (and I think we're in violent = >>agreement) that if you want a router address to be reachable, it = >>either has to be announced as a host route or as part of a subnet = >>route. If the interface isn't passing traffic, announcing a subnet = >>route would be an exceedingly poor idea, so the host route is the way = >>to go. The spec is properly (IMHO) silent on when to send host routes = >>in this case, as it is purely an implementation decision and is not = >>subject to standardization. >> > >I think this is implicit in the spec. One can ask OSPF to announce >some subnets and all matching interfaces are then announced, if you pull >the cable, the IP address still matches and is reachable so it >should still be announced as a host route. = > > 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 Wed Jan 7 21:09:27 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 915833A6A7B; Wed, 7 Jan 2009 21:09:27 -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 A32D53A6A7B for ; Wed, 7 Jan 2009 21:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=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 U3trmjw1EGKC for ; Wed, 7 Jan 2009 21:09:25 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 68F793A67B3 for ; Wed, 7 Jan 2009 21:09:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSWWKXGS7tOly3Q4tW5sNgflzkFbPdrDp@postini.com; Wed, 07 Jan 2009 21:09:12 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.336.0; Wed, 7 Jan 2009 21:06:51 -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); Wed, 7 Jan 2009 21:06:51 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 21:06:51 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 21:06:50 -0800 Received: from smentzer-t61.jnpr.net (smentzer-t61.jnpr.net [172.24.234.22] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0856nM87246; Wed, 7 Jan 2009 21:06:49 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <19FEE3B7-5220-47BC-A176-6F9ADFD783B6@juniper.net> From: Dave Katz To: joakim.tjernlund@transmode.se In-Reply-To: <1231349424.21348.244.camel@gentoo-jocke.transmode.se> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 7 Jan 2009 22:06:52 -0700 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <99473301-1D56-4C49-AFA9-F7663017379C@redback.com> <56D50EB7-D482-45D5-8CB4-EC53D4F52FCC@juniper.net> <1231349424.21348.244.camel@gentoo-jocke.transmode.se> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Jan 2009 05:06:50.0355 (UTC) FILETIME=[E9F8BC30:01C9714E] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 On Jan 7, 2009, at 10:30 AM, Joakim Tjernlund wrote: > On Tue, 2009-01-06 at 21:30 -0700, Dave Katz wrote: >> Well, *somebody* needs to advertise the address used as the source >> address for OSPF on unnumbered links, or the protocol will fail. The >> spec specifically says that the receiver of said packets is supposed >> to advertise that address. The spec does *not* say that the owner of >> that address should advertise it, as stupid as that may seem. > > Does it really have to be the source address used by the unnumbered > links? Isn't it enough to add any IP address used on the router? > So if you have at least one numbered interface in the area, you are > good. > If not, you will add a host route as footnote 2 says, usally done > with a loopback or dummy interface. The source address must be advertised somewhere (either as a host route or as part of a subnet route) or OSPF will fail; any unicast OSPF packets (such as retransmissions) will not be deliverable otherwise. > > >> >> Speaking of intent is all well and good, but the spec has been out >> there for about 20 years now and it says something else. John Moy's >> implementation is not the spec. >> >> In reality, implementors seem to end up doing the right thing anyhow. > > Which ones(besides Juniper)? According to Acee at least 4 commercial > vendors does not. I've long since lost track of what the "right thing" is. ;-) But there is an existence proof that unnumbered links work, so somebody is doing something right. Unless somebody changed it since I wrote it, the Juniper box advertises the neighbor's address (according to option 1) as well as its own as necessary. Note that there's nothing harmful in implementing both belts and suspenders here. > > >> >> (I still get grief for advertising the loopback address by default in >> our implementation, 11 years on, as that's not in the spec either.) >> But the spec, as written, works. Simply ignoring Option 1 for >> unnumbered links *breaks the spec*. Unless the spec is changed to >> specifically require that the address used as the source on >> unnumbered >> links is advertised in *some* LSA by the owner of said address, we >> cannot say that the clause as written is in error. > > The spec is fuzzy, for instance it says > "a Type 3 link (stub network) should be added" > "Should" isn't very strict and the text in Option 1 is also > a bit fuzzy so I would not say that omitting Option 1 breaks > the spec even in its current form. Well, don't get me started on the form of the OSPF spec. It predates the MUST/SHALL/SHOULD language, is incredibly fuzzy on what's normative and what's not, never explains most of why it does what it does, and is at least as much an implementation guide as a protocol spec. The good news is that you cannot build a scalable implementation by doing what the spec says to do; if it didn't hand implementors a guide, they might actually have to think about it, and those of us with industrial-scale implementations might have more competition... But it is the case that if you don't do Option 1, and your neighbor does not advertise a host route for its source address, the protocol will *not* work and thus the spec would be broken. > > > That said, I really think an official statement from IETF is > needed. Otherwise this issue will haunt OSPF for years to come. The problem is that there are 20 years of implementations out there, so any change whatsoever that is not backward compatible is arguably a non-starter. Discussing the issue and offering belts to go with suspenders is not a bad thing, however. --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 7 21:33:15 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 EBC683A687A; Wed, 7 Jan 2009 21:33: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 F217A3A68B8 for ; Wed, 7 Jan 2009 21:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 3znIdx7Tv0f0 for ; Wed, 7 Jan 2009 21:33:13 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id DACA63A67B3 for ; Wed, 7 Jan 2009 21:33:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSWWQCRuyIOWIWAtWKoXIl4cHzB6cmA1T@postini.com; Wed, 07 Jan 2009 21:33:00 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.336.0; Wed, 7 Jan 2009 21:30:14 -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); Wed, 7 Jan 2009 21:30:14 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 21:30:13 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 21:30:13 -0800 Received: from smentzer-t61.jnpr.net (smentzer-t61.jnpr.net [172.24.234.22] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n085U8M96410; Wed, 7 Jan 2009 21:30:10 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <1D5D3DA2-0CE6-47AF-AABD-2DAD113EA1D9@juniper.net> From: Dave Katz To: Richard Ogier In-Reply-To: <49658039.1090204@earthlink.net> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 7 Jan 2009 22:30:07 -0700 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <49658039.1090204@earthlink.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Jan 2009 05:30:13.0069 (UTC) FILETIME=[2E0DE7D0:01C97152] Cc: ospf@ietf.org, joakim.tjernlund@transmode.se Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 On Jan 7, 2009, at 9:25 PM, Richard Ogier wrote: > > I have found this discussion interesting and educational. > The above argument is very convincing, which I guess is why nobody > is arguing against it. Based on the discussion, I think RFC 2328 > should > be clarified as follows to allow some flexibility while ensuring > interoperability between different implementations (including most > existing implementations). > > - Footnote [2] MUST be implemented, i.e., if all of the router's > interfaces > are point-to-point links, then the router's IP address MUST be > advertised > in the router-LSA as a host route. If all the router's interfaces are *unnumbered* point-to-point links. This is, for the most part, an uninteresting degenerate case and doesn't apply to the broader problem here, which is who should be advertising the source address of OSPF packets sent on *any* unnumbered link, independent of what the other link types are. > > > - For unnumbered point-to-point links, a Type 3 link (stub network) > MAY be added to the router-LSA (Option 1), but is not required. > Although > adding such links may seem redundant, it has the benefit of ensuring > that > routes calculated to each router are *shortest* paths. Without > adding the > stub links, the calculated routing table will provide the shortest > path to > each network and host, but that need not result in the shortest path > to a > router that is not advertising its own IP address as a host route. > For example, the last hop of the shortest path might be via an > unnumbered > point-to-point link, but the last hop of the calculated path might be > via a numbered point-to-point link (which includes a stub link to the > destination router). Let me know if I am mistaken. This is presumably what the dreaded Option 1 attempted to do. It attracts traffic to the neighbor router, which will then resolve the last hop to the unnumbered link itself via the usual mechanisms for directly-connected neighbors. Of course, this only results in optimal routing if *all* of the links are unnumbered (so all of the neighbors are injecting the stub), but then footnote 2 kicks in and saves the day in the only case that actually works optimally. You are right that the only way to get optimal routing to the router in the general case is for the router itself to advertise a stub. I fail to see what's controversial about Option 1, save for the fact that it's suboptimal and a stupid way of solving the problem (rather than having the router owning the address advertise the route instead of its neighbors) and for the colloquial use of "should", which I always read as MUST in the more modern dialect. To me it is straightforwardly and unambiguously required for unnumbered links (just as Option 2 is required for subnetted links.) Other than substituting MUST for "should" I don't see any question about this. It is brain-dead six ways from Sunday (like a number of things in OSPF) but I think we're stuck with it due to backward compatibility issues. Unfortunately, I doubt there is no IETF equivalent of the Federalist Papers to try to give hints of the true intentions of the framers. (I was there, but didn't take notes, and was more interested in ISIS at the time anyhow.) As soon as we figure out what the 2nd Amendment was for, we can go on to Option 1. ;-) --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 7 22:54:49 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 361FE3A6A7B; Wed, 7 Jan 2009 22:54:49 -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 CBDCB3A6A7B for ; Wed, 7 Jan 2009 22:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Y+RH60xGckW6 for ; Wed, 7 Jan 2009 22:54:46 -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 B509B3A69FB for ; Wed, 7 Jan 2009 22:54:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iYnvERn8mzK2f+8ioWm/xoDq0Q2rSQvAklyp1HyRP65g6n2D1O0JjtxI0RaLibTU; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.221.26] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LKomj-0003Ro-4t; Thu, 08 Jan 2009 01:54:30 -0500 Message-ID: <4965A3CD.6090005@earthlink.net> Date: Wed, 07 Jan 2009 22:57:17 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Katz References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <49658039.1090204@earthlink.net> <1D5D3DA2-0CE6-47AF-AABD-2DAD113EA1D9@juniper.net> In-Reply-To: <1D5D3DA2-0CE6-47AF-AABD-2DAD113EA1D9@juniper.net> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4781111e4c6ff0530fa7d1b82a788939e12a92243df993c2de3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.26 Cc: ospf@ietf.org, joakim.tjernlund@transmode.se Subject: Re: [OSPF] Unnumbered PtoP router LSA 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" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Dave Katz wrote: > > On Jan 7, 2009, at 9:25 PM, Richard Ogier wrote: > >> >> I have found this discussion interesting and educational. >> The above argument is very convincing, which I guess is why nobody >> is arguing against it. Based on the discussion, I think RFC 2328 >> should >> be clarified as follows to allow some flexibility while ensuring >> interoperability between different implementations (including most >> existing implementations). >> >> - Footnote [2] MUST be implemented, i.e., if all of the router's >> interfaces >> are point-to-point links, then the router's IP address MUST be >> advertised >> in the router-LSA as a host route. > > > If all the router's interfaces are *unnumbered* point-to-point > links. This is, for the most part, an uninteresting degenerate case > and doesn't apply to the broader problem here, which is who should > be advertising the source address of OSPF packets sent on *any* > unnumbered link, independent of what the other link types are. > >> >> >> - For unnumbered point-to-point links, a Type 3 link (stub network) >> MAY be added to the router-LSA (Option 1), but is not required. >> Although >> adding such links may seem redundant, it has the benefit of ensuring >> that >> routes calculated to each router are *shortest* paths. Without >> adding the >> stub links, the calculated routing table will provide the shortest >> path to >> each network and host, but that need not result in the shortest path >> to a >> router that is not advertising its own IP address as a host route. >> For example, the last hop of the shortest path might be via an >> unnumbered >> point-to-point link, but the last hop of the calculated path might be >> via a numbered point-to-point link (which includes a stub link to the >> destination router). Let me know if I am mistaken. > > > This is presumably what the dreaded Option 1 attempted to do. It > attracts traffic to the neighbor router, which will then resolve the > last hop to the unnumbered link itself via the usual mechanisms for > directly-connected neighbors. Of course, this only results in > optimal routing if *all* of the links are unnumbered (so all of the > neighbors are injecting the stub), but then footnote 2 kicks in and > saves the day in the only case that actually works optimally. I am assuming that a stub link is always required for *numbered* point-to-point links (as per RFC 2328), and is optional for *unnumbered* links (my suggestion). So this allows optimal routing even if only some of the links are unnumbered, by allowing Option 1 to be used for all point-to-point links. (Maybe I wasn't clear about this.) My point is that some people might think it is redundant to advertise stub links for unnumbered links, but there is a benefit - optimal routing to all routers. In addition, Footnote 2 is required to ensure interoperability with routers that decide not to use Option 1 for unnumbered links. The resulting clarification to RFC 2328 allows optimal routing to all routers (optionally), while hopefully complying with almost all existing implementations. Let me know if I am mistaken. Richard > > You are right that the only way to get optimal routing to the router > in the general case is for the router itself to advertise a stub. > > I fail to see what's controversial about Option 1, save for the fact > that it's suboptimal and a stupid way of solving the problem (rather > than having the router owning the address advertise the route instead > of its neighbors) and for the colloquial use of "should", which I > always read as MUST in the more modern dialect. To me it is > straightforwardly and unambiguously required for unnumbered links > (just as Option 2 is required for subnetted links.) Other than > substituting MUST for "should" I don't see any question about this. > It is brain-dead six ways from Sunday (like a number of things in > OSPF) but I think we're stuck with it due to backward compatibility > issues. > > Unfortunately, I doubt there is no IETF equivalent of the Federalist > Papers to try to give hints of the true intentions of the framers. > (I was there, but didn't take notes, and was more interested in ISIS > at the time anyhow.) As soon as we figure out what the 2nd Amendment > was for, we can go on to Option 1. ;-) > > --Dave > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From nour@4ssphinx.com Thu Jan 8 00:50:13 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B280F28C15A for ; Thu, 8 Jan 2009 00:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.545 X-Spam-Level: X-Spam-Status: No, score=-13.545 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 Ngtbe4hgTkTp for ; Thu, 8 Jan 2009 00:50:13 -0800 (PST) Received: from ahm.honda.com (unknown [71.8.0.34]) by core3.amsl.com (Postfix) with SMTP id 1C7273A6827 for ; Thu, 8 Jan 2009 00:50:11 -0800 (PST) To: Subject: Your order 83811 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090108085012.1C7273A6827@core3.amsl.com> Date: Thu, 8 Jan 2009 00:50:11 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 32142
From lacye_tennilled@ama-assn.org Thu Jan 8 04:09:28 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AA603A6A4A for ; Thu, 8 Jan 2009 04:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.247 X-Spam-Level: X-Spam-Status: No, score=-9.247 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 RinwWBHajR-P for ; Thu, 8 Jan 2009 04:09:28 -0800 (PST) Received: from p7010-ipbfp901fukuokachu.fukuoka.ocn.ne.jp (p7010-ipbfp901fukuokachu.fukuoka.ocn.ne.jp [118.5.206.10]) by core3.amsl.com (Postfix) with SMTP id 107FB3A691F for ; Thu, 8 Jan 2009 04:09:25 -0800 (PST) To: Subject: Let's meet as usually From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090108120926.107FB3A691F@core3.amsl.com> Date: Thu, 8 Jan 2009 04:09:25 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ospf-bounces@ietf.org Thu Jan 8 09:02: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 131263A6B03; Thu, 8 Jan 2009 09:02:44 -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 764603A6A2E for ; Thu, 8 Jan 2009 09:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Aj0PF1WK4-5V for ; Thu, 8 Jan 2009 09:02:42 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 499EA3A676A for ; Thu, 8 Jan 2009 09:02:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cdwGbYc0yFiqrF1t+/uAVNXMalT0iHNwgPZVJ5jQyewWD6dOnl9T4fSGaNbMyEpH; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.221.74] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LKyGz-0005RM-D6; Thu, 08 Jan 2009 12:02:23 -0500 Message-ID: <49663239.5050103@earthlink.net> Date: Thu, 08 Jan 2009 09:04:57 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Katz References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <49658039.1090204@earthlink.net> <1D5D3DA2-0CE6-47AF-AABD-2DAD113EA1D9@juniper.net> In-Reply-To: <1D5D3DA2-0CE6-47AF-AABD-2DAD113EA1D9@juniper.net> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4781111e4c6ff0530fa78692785bc5247b5bba287e25e53deea350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.74 Cc: ospf@ietf.org, joakim.tjernlund@transmode.se Subject: Re: [OSPF] Unnumbered PtoP router LSA 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" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org I have an additional comment below. (My last comment is also repated below.) Dave Katz wrote: > > On Jan 7, 2009, at 9:25 PM, Richard Ogier wrote: > >> >> I have found this discussion interesting and educational. >> The above argument is very convincing, which I guess is why nobody >> is arguing against it. Based on the discussion, I think RFC 2328 >> should >> be clarified as follows to allow some flexibility while ensuring >> interoperability between different implementations (including most >> existing implementations). >> >> - Footnote [2] MUST be implemented, i.e., if all of the router's >> interfaces >> are point-to-point links, then the router's IP address MUST be >> advertised >> in the router-LSA as a host route. > > > If all the router's interfaces are *unnumbered* point-to-point > links. This is, for the most part, an uninteresting degenerate case > and doesn't apply to the broader problem here, which is who should > be advertising the source address of OSPF packets sent on *any* > unnumbered link, independent of what the other link types are. > >> >> >> - For unnumbered point-to-point links, a Type 3 link (stub network) >> MAY be added to the router-LSA (Option 1), but is not required. >> Although >> adding such links may seem redundant, it has the benefit of ensuring >> that >> routes calculated to each router are *shortest* paths. Without >> adding the >> stub links, the calculated routing table will provide the shortest >> path to >> each network and host, but that need not result in the shortest path >> to a >> router that is not advertising its own IP address as a host route. >> For example, the last hop of the shortest path might be via an >> unnumbered >> point-to-point link, but the last hop of the calculated path might be >> via a numbered point-to-point link (which includes a stub link to the >> destination router). Let me know if I am mistaken. > > > This is presumably what the dreaded Option 1 attempted to do. It > attracts traffic to the neighbor router, which will then resolve the > last hop to the unnumbered link itself via the usual mechanisms for > directly-connected neighbors. Of course, this only results in > optimal routing if *all* of the links are unnumbered (so all of the > neighbors are injecting the stub), but then footnote 2 kicks in and > saves the day in the only case that actually works optimally. I am assuming that a stub link is always required for *numbered* point-to-point links (as per RFC 2328), and is optional for *unnumbered* links (my suggestion). So this allows optimal routing even if only some of the links are unnumbered, by allowing Option 1 to be used for all point-to-point links. (Maybe I wasn't clear about this.) My point is that some people might think it is redundant to advertise stub links for unnumbered links, but there is a benefit - optimal routing to all routers. In addition, Footnote 2 is required to ensure interoperability with routers that decide not to use Option 1 for unnumbered links. The resulting clarification to RFC 2328 allows optimal routing to all routers (optionally), while hopefully complying with almost all existing implementations. > > You are right that the only way to get optimal routing to the router > in the general case is for the router itself to advertise a stub. Yes, another way to ensure optimal routing to all routers is to have every router advertise its IP address as a stub link. Obviously, this can also be done optionally if optimal routing is desired. Therefore, my suggested clarification of RFC 2328 can be summarized as follows: - Footnote 2 MUST be implemented. - Option 1 is optional for unnumbered point-to-point links. - Any router MAY advertise its IP address as a stub link, to ensure optimal routing. > > I fail to see what's controversial about Option 1, save for the fact > that it's suboptimal and a stupid way of solving the problem (rather > than having the router owning the address advertise the route instead > of its neighbors) and for the colloquial use of "should", which I > always read as MUST in the more modern dialect. To me it is > straightforwardly and unambiguously required for unnumbered links > (just as Option 2 is required for subnetted links.) Other than > substituting MUST for "should" I don't see any question about this. > It is brain-dead six ways from Sunday (like a number of things in > OSPF) but I think we're stuck with it due to backward compatibility > issues. Since Footnote 2 was already required by RFC 2328 (and hopefully your implementations are compliant with this), then making Option 1 optional for unnumbered links is backward compatible, even if you interpreted the RFC to require Option 1 for unnumbered links (which as Acee stated was not the intention.) Let me know if I am mistaken. Richard > > Unfortunately, I doubt there is no IETF equivalent of the Federalist > Papers to try to give hints of the true intentions of the framers. > (I was there, but didn't take notes, and was more interested in ISIS > at the time anyhow.) As soon as we figure out what the 2nd Amendment > was for, we can go on to Option 1. ;-) > > --Dave > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jan 8 12:37:56 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 02F463A6962; Thu, 8 Jan 2009 12:37:56 -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 1CF0F3A657C for ; Thu, 8 Jan 2009 12:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_42=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 LA+awx-uKHX1 for ; Thu, 8 Jan 2009 12:37:53 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id B0F243A6962 for ; Thu, 8 Jan 2009 12:37:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fi3T8jOve8ya7O7K84LKRmlUWFjlmNLS3igdbn1WUAY91cZ7eSUGGJDkE6klwRGv; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.217.194] by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LL1dJ-0003KJ-PT; Thu, 08 Jan 2009 15:37:40 -0500 Message-ID: <496664BB.7030807@earthlink.net> Date: Thu, 08 Jan 2009 12:40:27 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: joakim.tjernlund@transmode.se References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> In-Reply-To: <1231337929.21348.177.camel@gentoo-jocke.transmode.se> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4781111e4c6ff0530fa18b50bbb13c047caa0a3b559bdf9f88c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.217.194 Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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: quoted-printable Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Jocke, Here is one more piece of evidence (to add to your already convincing evidence below), which makes it clear that stub links are required for point-to-point links only when interface addresses are assigned. The following is from RFC 2328, page 15. "Interfaces to point-to-point networks need not be assigned IP addresses. When interface addresses are assigned, they are modelled as stub links, with each router advertising a stub connection to the other router's interface address. Optionally, an IP subnet can be assigned to the point- to-point network. In this case, both routers advertise a stub link to the IP subnet, instead of advertising each others' IP interface addresses." There is no longer any doubt in my mind about this. The main clarification is that Footnote 2 MUST be implemented. One can always add stub links that are not required. Richard Joakim Tjernlund wrote: >On Tue, 2009-01-06 at 16:34 -0700, Dave Katz wrote: > = > >>On Jan 6, 2009, at 2:19 PM, Joakim Tjernlund wrote: >> >> = >> >>>>The footnote is sort of bogus on three counts. First of all, a = >>>>router >>>>*must* have an address somewhere, or it has nothing to put in the IP >>>>source address field, can't be managed, and is an incredibly = >>>>expensive >>>>door stop. So that bit is redundant. >>>> = >>>> >>>Obviously an IP address is needed, the key part is that the IP address >>>should be announced as an host route in the router LSA. >>> >>> = >>> >>>>Secondly, there is no explicit >>>>mechanism in the spec for advertising that host route, unless this >>>>sentence is intended to be normative (in which case the "will" should >>>>be a "SHALL".) >>>> = >>>> >>>What mechanism do you need? It is an impl. detail how you specify >>>that IP address, if you need one. Will vs. shall is perhaps an = >>>error, I can't >>>say, but I don't think the language in Option 1 or Option 2 is any = >>>stronger. >>> >>> = >>> >>>>Thirdly, if implementations were to actually follow >>>>the other section you mention and do option 1, advertising that host >>>>route is unnecessary because all of the OSPF neighbors will know the >>>>address and advertise it themselves (roundabout, as mentioned = >>>>earlier, >>>>but it works.) And that footnote is much narrower than the case we >>>>are talking about, which is that of *any* unnumbered interface, >>>>regardless of whether there are other numbered interfaces or not. >>>> = >>>> >>>You only have do this iff you just have unnumbered interfaces, no need >>>to add an extra host route if you already announce one. >>> = >>> >>I think we've gone in circles here. >> >>If I understood your original posting, you were asking about the = >>meaning/value of the options listed as part of 12.4.1.1. The reason = >>that they are there is to ensure reachability to the remote router = >>itself, if it implements exactly what the spec says to do. If the = >>local router doesn't do Option 1, and the remote router only does = >>exactly what the spec says to do, you will not be able to route to the = >>remote router because nobody will announce reachability to its address. >> >>One can look at the spec and say, "of course I should announce host = >>routes for addresses I think the world might be interested in", and it = >>will work, but the spec never actually says to do that, *except* in = >>the case of a router with no numbered interfaces at all (and burying = >>it in a footnote at the very end of the spec is not a terribly good = >>thing even in that case.) >> >>So a na=EFve implementor will still have a functional, reachable, = >>manageable network if he implements Option 1 and doesn't advertise any = >>host routes otherwise. This is why Option 1 exists, and why it is = >>normative. If my box is neighbor to the the na=EFve implementor's box, = >>and I don't do Option 1, and he doesn't have his loopback address or = >>some other address outside of OSPF in a host route (perfectly in- = >>spec), his box is going to be unreachable for management purposes. >> = >> > >I would not say that it is "perfectly in spec" as the spec actually >mentions this case explicitly in that footnote. I guess that the spec >assumes that it is very uncommon to just have unnumbered links is the >domain and that is perhaps why it is in a footnote. > >Also I can can't find a reference in the spec that states that >the purpose of Option 1 is reachability, in [15] one can read: = >[15]This is the way RFC 1583 specified point-to-point > representation. It has three advantages: a) it does not require > allocating a subnet to the point-to-point link, b) it tends to bias > the routing so that packets destined for the point-to-point > interface will actually be received over the interface (which is > useful for diagnostic purposes) and c) it allows network > bootstrapping of a neighbor, without requiring that the bootstrap > program contain an OSPF implementation. > >Further, looking into RFC 1583 one can see that Option 1 isn't used for >unnumbered links. > >Also, there would be no need for footnote [2] if Option 1 is required >so why have in the first place? > >Actully, the only thing that might suggest that Option 1 should be >used in 2328 is the text i Option 1 and that text is a bit "fuzzy". >Everything else suggests that Option 1 should not be used(in my reading) > > = > >>Maybe I'm missing something here? >> >> = >> >>> = >>> >>>>>An related question: what to do with an interface that is UP but not >>>>>RUNNING? >>>>> = >>>>> >>>>Given that these terms are not well-defined, it's not possible to >>>>answer in a normative way. Even in a non-normative, casual way, it's >>>>not clear to me what the actual difference is. If the link does not >>>>pass packets, for whatever reason, OSPF will not come up, and traffic >>>>will not be passed to the nonfunctional link. Whether that interface >>>>address is advertised by the offending router is an implementation >>>>decision, as it has no functional use other than as a management >>>>address. For that matter, it is then immaterial as to whether the >>>>interface is "up" in any way or not, since there's no traffic going = >>>>to >>>>that interface anyhow. One could choose to advertise *all* interface >>>>addresses as host routes whether the interface is up or not, in case >>>>anybody is sending packets to those addresses from afar. But this is >>>>usually done with loopback addresses, which become the "router >>>>address" for management purposes and are independent of any physical >>>>hardware. >>>> = >>>> >>>The IP address on that link is still reachable through other = >>>interfaces. If you >>>have a connection to the router using its IP address, you can still = >>>use it >>>even if the interface isn't RUNNING(i.e someone pulled the cable for = >>>that interface). >>>So instead of removing the whole interface and its subnet from the = >>>OSPF domain, one >>>should change the router LSA to announce a host route with that = >>>interface's IP address. >>> = >>> >>I guess I still don't understand the distinction between UP and = >>RUNNING, but that's OK. >> = >> > >Sorry, I should have explained this better. I refering to the >status of the interface as returned by ifconfig: ># > ifconfig eth0 >eth0 Link encap:Ethernet HWaddr 00:06:9C:00:20:02 = > inet addr:10.0.1.1 Bcast:10.0.255.255 Mask:255.255.0.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > >If I disconnect the ethernet cable, the RUNNING status goes away since >the interface cannot pass traffic on the ethernet, but the interface is >still UP. > >What does Juniper do in this case for an interface that is part >of a OSPF area? I really like to find out how other routers handle >this case. = > = > = > >>The point is (and I think we're in violent = >>agreement) that if you want a router address to be reachable, it = >>either has to be announced as a host route or as part of a subnet = >>route. If the interface isn't passing traffic, announcing a subnet = >>route would be an exceedingly poor idea, so the host route is the way = >>to go. The spec is properly (IMHO) silent on when to send host routes = >>in this case, as it is purely an implementation decision and is not = >>subject to standardization. >> = >> > >I think this is implicit in the spec. One can ask OSPF to announce >some subnets and all matching interfaces are then announced, if you pull >the cable, the IP address still matches and is reachable so it >should still be announced as a host route. = > > 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 Thu Jan 8 15:08:48 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 3B8A03A6AB3; Thu, 8 Jan 2009 15:08:48 -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 F0D113A6AB3 for ; Thu, 8 Jan 2009 15:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HELO_EQ_SE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfwsETE1A4C9 for ; Thu, 8 Jan 2009 15:08:46 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id C6EA23A67F8 for ; Thu, 8 Jan 2009 15:08:44 -0800 (PST) Received: from jockexp ([192.168.105.34]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Jan 2009 00:08:19 +0100 From: "Joakim Tjernlund" To: "'Dave Katz'" References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <99473301-1D56-4C49-AFA9-F7663017379C@redback.com> <56D50EB7-D482-45D5-8CB4-EC53D4F52FCC@juniper.net> <1231349424.21348.244.camel@gentoo-jocke.transmode.se> <19FEE3B7-5220-47BC-A176-6F9ADFD783B6@juniper.net> In-Reply-To: <19FEE3B7-5220-47BC-A176-6F9ADFD783B6@juniper.net> Date: Fri, 9 Jan 2009 00:08:12 +0100 Message-ID: <01ae01c971e5$fae486e0$f0ad94a0$@Tjernlund@transmode.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclxTzwDSMaXWwBhTKOvQFJlpoDu1AAlHTQA Content-Language: sv X-OriginalArrivalTime: 08 Jan 2009 23:08:19.0897 (UTC) FILETIME=[FF271290:01C971E5] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 Sorry for being a bit late, work has been chaotic ... > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: den 8 januari 2009 06:07 > To: joakim.tjernlund@transmode.se > Cc: Acee Lindem; ospf@ietf.org > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > > On Jan 7, 2009, at 10:30 AM, Joakim Tjernlund wrote: > > > On Tue, 2009-01-06 at 21:30 -0700, Dave Katz wrote: > >> Well, *somebody* needs to advertise the address used as the source > >> address for OSPF on unnumbered links, or the protocol will fail. The > >> spec specifically says that the receiver of said packets is supposed > >> to advertise that address. The spec does *not* say that the owner of > >> that address should advertise it, as stupid as that may seem. > > > > Does it really have to be the source address used by the unnumbered > > links? Isn't it enough to add any IP address used on the router? > > So if you have at least one numbered interface in the area, you are > > good. > > If not, you will add a host route as footnote 2 says, usally done > > with a loopback or dummy interface. > > The source address must be advertised somewhere (either as a host > route or as part of a subnet route) or OSPF will fail; any unicast > OSPF packets (such as retransmissions) will not be deliverable > otherwise. This I don't understand, why can't it be any address on the router? > > > > > [SNIP] > > But it is the case that if you don't do Option 1, and your neighbor > does not advertise a host route for its source address, the protocol > will *not* work and thus the spec would be broken. > I see why you need to announce a host route from the neighbor but I don't understand why it has to the same IP address used for the PtoP link. You asked earlier why I wanted to drop Option 1 for unnumbered links, it is mostly because I think I it can have an impact on OSPF performance. Consider a OSPF area with almost only PtoP links, adding Option 1 makes the Router LSA almost twice as big and there will be lots of extra stub links to process for little use. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jan 8 15:16:45 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 06A423A68A9; Thu, 8 Jan 2009 15:16:45 -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 C79D83A67FD for ; Thu, 8 Jan 2009 15:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HELO_EQ_SE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tGO9FIqJBwX for ; Thu, 8 Jan 2009 15:16:43 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id B69383A67A3 for ; Thu, 8 Jan 2009 15:16:42 -0800 (PST) Received: from jockexp ([192.168.105.34]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Jan 2009 00:16:21 +0100 From: "Joakim Tjernlund" To: "'Richard Ogier'" References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <496664BB.7030807@earthlink.net> In-Reply-To: <496664BB.7030807@earthlink.net> Date: Fri, 9 Jan 2009 00:16:14 +0100 Message-ID: <01b101c971e7$1a322dd0$4e968970$@Tjernlund@transmode.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aclx0PCRJ8a3clH/Siuz87Rp8ynlXAAFRiMA Content-Language: sv X-OriginalArrivalTime: 08 Jan 2009 23:16:21.0915 (UTC) FILETIME=[1E752EB0:01C971E7] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 > -----Original Message----- > From: Richard Ogier [mailto:ogier@earthlink.net] > Sent: den 8 januari 2009 21:40 > To: joakim.tjernlund@transmode.se > Cc: ospf@ietf.org > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > Jocke, > > Here is one more piece of evidence (to add to your already convincing > evidence below), which makes it clear that stub links are required > for point-to-point links only when interface addresses are assigned. > The following is from RFC 2328, page 15. > > "Interfaces to point-to-point networks need > not be assigned IP addresses. When interface addresses are > assigned, they are modelled as stub links, with each router > advertising a stub connection to the other router's interface > address. Optionally, an IP subnet can be assigned to the point- > to-point network. In this case, both routers advertise a stub > link to the IP subnet, instead of advertising each others' IP > interface addresses." > > There is no longer any doubt in my mind about this. The main > clarification is that Footnote 2 MUST be implemented. > One can always add stub links that are not required. > > Richard Thanks I do think however that Dave has a point. There are probably impl. out there that does Option 1, but does not include a host route to itself. Such routers will probably have a hard time working with an router not doing Option 1. I suspect that footnote 2 isn't enough, one must announce an host route as soon as one have 1 or more unnumbered links. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jan 8 16:13:33 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 A39163A68F9; Thu, 8 Jan 2009 16:13:33 -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 13AD13A68F9 for ; Thu, 8 Jan 2009 16:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 PcmAahcJErcs for ; Thu, 8 Jan 2009 16:13:31 -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 CE9583A6836 for ; Thu, 8 Jan 2009 16:13:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jytjzsqz95Q/XBML19e1t8/K0QOSfHUMiizLbjb1eBy4naXDN1/hPCTfPAuORJQE; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.216.247] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LL4zz-0000FA-Tz; Thu, 08 Jan 2009 19:13:17 -0500 Message-ID: <49669745.6040104@earthlink.net> Date: Thu, 08 Jan 2009 16:16:05 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joakim Tjernlund References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <496664BB.7030807@earthlink.net> <01b101c971e7$1a322dd0$4e968970$@Tjernlund@transmode.se> In-Reply-To: <01b101c971e7$1a322dd0$4e968970$@Tjernlund@transmode.se> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4781111e4c6ff0530faf610a772d0d1bd61418c56abb3365191350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.216.247 Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Joakim Tjernlund wrote: >>-----Original Message----- >>From: Richard Ogier [mailto:ogier@earthlink.net] >>Sent: den 8 januari 2009 21:40 >>To: joakim.tjernlund@transmode.se >>Cc: ospf@ietf.org >>Subject: Re: [OSPF] Unnumbered PtoP router LSA question. >> >>Jocke, >> >>Here is one more piece of evidence (to add to your already convincing >>evidence below), which makes it clear that stub links are required >>for point-to-point links only when interface addresses are assigned. >>The following is from RFC 2328, page 15. >> >> "Interfaces to point-to-point networks need >> not be assigned IP addresses. When interface addresses are >> assigned, they are modelled as stub links, with each router >> advertising a stub connection to the other router's interface >> address. Optionally, an IP subnet can be assigned to the point- >> to-point network. In this case, both routers advertise a stub >> link to the IP subnet, instead of advertising each others' IP >> interface addresses." >> >>There is no longer any doubt in my mind about this. The main >>clarification is that Footnote 2 MUST be implemented. >>One can always add stub links that are not required. >> >>Richard >> >> > >Thanks > >I do think however that Dave has a point. There are probably impl. >out there that does Option 1, but does not include a host route >to itself. Such routers will probably have a hard time working >with an router not doing Option 1. >I suspect that footnote 2 isn't enough, one must announce an host >route as soon as one have 1 or more unnumbered links. > > Jocke > > If your suspicion is correct that Footnote 2 isn't enough, then that would be an error in RFC 2328, since as we seem to agree, the RFC does not require doing Option 1 for unnumbered links. However, I am not sure your suspicion is correct. Do you have an example that shows Footnote 2 is not enough to ensure each router is reachable? I agree that if one wants to ensure *optimal* routes to each router, then a router must announce a host route when it has 1 or more unnumbered links. (I can give an example to show this.) But there is no requirement of optimal routes for management purposes. Richard > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 9 01:47:01 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 3F6443A68CB; Fri, 9 Jan 2009 01:47:01 -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 4C7253A68BD for ; Fri, 9 Jan 2009 01:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=1.288, 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 Bt29pKyABBqJ for ; Fri, 9 Jan 2009 01:46:58 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 135603A68CB for ; Fri, 9 Jan 2009 01:46:57 -0800 (PST) Received: mail.transmode.se 192.168.46.15 from 192.168.1.15 192.168.1.15 via HTTP with MS-WebStorage 6.0.6249 Received: from gentoo-jocke by mail.transmode.se; 09 Jan 2009 10:46:41 +0100 From: Joakim Tjernlund To: Richard Ogier In-Reply-To: <49669745.6040104@earthlink.net> References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <496664BB.7030807@earthlink.net> <01b101c971e7$1a322dd0$4e968970$@Tjernlund@transmode.se> <49669745.6040104@earthlink.net> Organization: Transmode AB Date: Fri, 09 Jan 2009 10:46:41 +0100 Message-Id: <1231494401.5831.28.camel@gentoo-jocke.transmode.se> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA question. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joakim.tjernlund@transmode.se 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 On Thu, 2009-01-08 at 16:16 -0800, Richard Ogier wrote: > Joakim Tjernlund wrote: > > >>-----Original Message----- > >>From: Richard Ogier [mailto:ogier@earthlink.net] > >>Sent: den 8 januari 2009 21:40 > >>To: joakim.tjernlund@transmode.se > >>Cc: ospf@ietf.org > >>Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > >> > >>Jocke, > >> > >>Here is one more piece of evidence (to add to your already convincing > >>evidence below), which makes it clear that stub links are required > >>for point-to-point links only when interface addresses are assigned. > >>The following is from RFC 2328, page 15. > >> > >> "Interfaces to point-to-point networks need > >> not be assigned IP addresses. When interface addresses are > >> assigned, they are modelled as stub links, with each router > >> advertising a stub connection to the other router's interface > >> address. Optionally, an IP subnet can be assigned to the point- > >> to-point network. In this case, both routers advertise a stub > >> link to the IP subnet, instead of advertising each others' IP > >> interface addresses." > >> > >>There is no longer any doubt in my mind about this. The main > >>clarification is that Footnote 2 MUST be implemented. > >>One can always add stub links that are not required. > >> > >>Richard > >> > >> > > > >Thanks > > > >I do think however that Dave has a point. There are probably impl. > >out there that does Option 1, but does not include a host route > >to itself. Such routers will probably have a hard time working > >with an router not doing Option 1. > >I suspect that footnote 2 isn't enough, one must announce an host > >route as soon as one have 1 or more unnumbered links. > > > > Jocke > > > > > > If your suspicion is correct that Footnote 2 isn't enough, then that > would be an error in RFC 2328, since as we seem to agree, the RFC > does not require doing Option 1 for unnumbered links. > > However, I am not sure your suspicion is correct. Do you have an > example that shows Footnote 2 is not enough to ensure each router is > reachable? I agree that if one wants to ensure *optimal* routes to > each router, then a router must announce a host route when it has 1 > or more unnumbered links. (I can give an example to show this.) > But there is no requirement of optimal routes for management purposes. > > Richard If I understand Dave correctly, the host route announced must be the IP address used by the unnumbered PtoP links, I don't understand this requirement though so I hope Dave is wrong. Assuming Dave is wrong, and you just need some host route announced, there is nothing I can see that forces OSPF to announce such route iff there are other numbered interfaces too. If it is enough with any route, such as an subnet from an Ethernet interface, I believe most routers stops announcing this subnet if the Ethernet cable is pulled. I believe that if one pull the cable from an Ethernet interface, the router should turn the announced subnet into a host route of type Loop back instead, this is actually my next point I want to discuss so any comments on this would be much appreciated. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 9 07:04:38 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 D65263A6869; Fri, 9 Jan 2009 07:04:38 -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 D54213A68FF for ; Fri, 9 Jan 2009 07:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 AT2Li7TlmMOq for ; Fri, 9 Jan 2009 07:04:32 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id DFF953A6358 for ; Fri, 9 Jan 2009 07:04:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A6E7AA3E3AE; Fri, 9 Jan 2009 07:04:19 -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 08384-10; Fri, 9 Jan 2009 07:04:19 -0800 (PST) Received: from [IPv6???1] (lxlogin-4-300.redback.com [155.53.12.219]) by prattle.redback.com (Postfix) with ESMTP id 1160320F423; Fri, 9 Jan 2009 06:51:51 -0800 (PST) In-Reply-To: <1231494401.5831.28.camel@gentoo-jocke.transmode.se> References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <496664BB.7030807@earthlink.net> <01b101c971e7$1a322dd0$4e968970$@Tjernlund@transmode.se> <49669745.6040104@earthlink.net> <1231494401.5831.28.camel@gentoo-jocke.transmode.se> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <551F394B-3E9E-40FA-B6F3-E84BE7FBCC20@redback.com> From: Acee Lindem Date: Fri, 9 Jan 2009 09:51:52 -0500 To: joakim.tjernlund@transmode.se X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 I agree that advertising the interface address being borrowed by IPv4 unnumbered links is necessary for using that address as an endpoint for any IPv4 application (including OSPF virtual links). However, the protocol is not intended to so this automatically. Rather, that that interface should be configured to be advertised. Consider the case where you have many parallel unnumbered links between two routers - it makes much more sense for the unnumbered address to be advertised a single link than once for each unnumbered link. Thanks, Acee On Jan 9, 2009, at 4:46 AM, Joakim Tjernlund wrote: > On Thu, 2009-01-08 at 16:16 -0800, Richard Ogier wrote: >> Joakim Tjernlund wrote: >> >>>> -----Original Message----- >>>> From: Richard Ogier [mailto:ogier@earthlink.net] >>>> Sent: den 8 januari 2009 21:40 >>>> To: joakim.tjernlund@transmode.se >>>> Cc: ospf@ietf.org >>>> Subject: Re: [OSPF] Unnumbered PtoP router LSA question. >>>> >>>> Jocke, >>>> >>>> Here is one more piece of evidence (to add to your already >>>> convincing >>>> evidence below), which makes it clear that stub links are required >>>> for point-to-point links only when interface addresses are >>>> assigned. >>>> The following is from RFC 2328, page 15. >>>> >>>> "Interfaces to point-to-point networks need >>>> not be assigned IP addresses. When interface addresses are >>>> assigned, they are modelled as stub links, with each router >>>> advertising a stub connection to the other router's interface >>>> address. Optionally, an IP subnet can be assigned to the point- >>>> to-point network. In this case, both routers advertise a stub >>>> link to the IP subnet, instead of advertising each others' IP >>>> interface addresses." >>>> >>>> There is no longer any doubt in my mind about this. The main >>>> clarification is that Footnote 2 MUST be implemented. >>>> One can always add stub links that are not required. >>>> >>>> Richard >>>> >>>> >>> >>> Thanks >>> >>> I do think however that Dave has a point. There are probably impl. >>> out there that does Option 1, but does not include a host route >>> to itself. Such routers will probably have a hard time working >>> with an router not doing Option 1. >>> I suspect that footnote 2 isn't enough, one must announce an host >>> route as soon as one have 1 or more unnumbered links. >>> >>> Jocke >>> >>> >> >> If your suspicion is correct that Footnote 2 isn't enough, then that >> would be an error in RFC 2328, since as we seem to agree, the RFC >> does not require doing Option 1 for unnumbered links. >> >> However, I am not sure your suspicion is correct. Do you have an >> example that shows Footnote 2 is not enough to ensure each router is >> reachable? I agree that if one wants to ensure *optimal* routes to >> each router, then a router must announce a host route when it has 1 >> or more unnumbered links. (I can give an example to show this.) >> But there is no requirement of optimal routes for management >> purposes. >> >> Richard > > If I understand Dave correctly, the host route announced must be > the IP address used by the unnumbered PtoP links, I don't understand > this requirement though so I hope Dave is wrong. > > Assuming Dave is wrong, and you just need some host route announced, > there is nothing I can see that forces OSPF to announce such route iff > there are other numbered interfaces too. > > If it is enough with any route, such as an subnet from an Ethernet > interface, I believe most routers stops announcing this subnet if > the Ethernet cable is pulled. > I believe that if one pull the cable from an Ethernet interface, the > router should turn the announced subnet into a host route of type Loop > back instead, this is actually my next point I want to discuss > so any comments on this would be much appreciated. > > 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 Fri Jan 9 07:42:45 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 557853A683A; Fri, 9 Jan 2009 07:42:45 -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 189C53A683A for ; Fri, 9 Jan 2009 07:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ELA6qG-NNBjy for ; Fri, 9 Jan 2009 07:42:43 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id BDDFF3A680D for ; Fri, 9 Jan 2009 07:42:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSWdwTG6NZcw4RzEljF6IyxxR7MV6pUUw@postini.com; Fri, 09 Jan 2009 07:42:23 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.336.0; Fri, 9 Jan 2009 07:40:27 -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, 9 Jan 2009 07:40:27 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 07:40:27 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jan 2009 07:40:26 -0800 Received: from scarlson-lt.jnpr.net (scarlson-lt.jnpr.net [172.24.234.18] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n09FeQM82351; Fri, 9 Jan 2009 07:40:26 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: joakim.tjernlund@transmode.se In-Reply-To: <1231494401.5831.28.camel@gentoo-jocke.transmode.se> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 9 Jan 2009 10:40:25 -0500 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <496664BB.7030807@earthlink.net> <01b101c971e7$1a322dd0$4e968970$@Tjernlund@transmode.se> <49669745.6040104@earthlink.net> <1231494401.5831.28.camel@gentoo-jocke.transmode.se> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Jan 2009 15:40:26.0830 (UTC) FILETIME=[97F836E0:01C97270] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 On Jan 9, 2009, at 4:46 AM, Joakim Tjernlund wrote: > > If I understand Dave correctly, the host route announced must be > the IP address used by the unnumbered PtoP links, I don't understand > this requirement though so I hope Dave is wrong. Actually, I'm wrong. Most (probably all) implementations don't route their OSPF packets, but blast them out interfaces directly. I got hung up on the fact that, without such an announcement, nobody could route to that source address, but it doesn't matter (typically). Mea culpa. > > > Assuming Dave is wrong, and you just need some host route announced, > there is nothing I can see that forces OSPF to announce such route iff > there are other numbered interfaces too. True. > > > If it is enough with any route, such as an subnet from an Ethernet > interface, I believe most routers stops announcing this subnet if > the Ethernet cable is pulled. Typically true. > > I believe that if one pull the cable from an Ethernet interface, the > router should turn the announced subnet into a host route of type Loop > back instead, this is actually my next point I want to discuss > so any comments on this would be much appreciated. And that's an implementation decision that should be outside the scope of the spec. I'll fall on my sword here and say that there is no fundamental need to announce any router address by anybody unless the router wants to be reachable (a useful thing indeed, but not necessary to the functioning of the protocol.) --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 9 08:12:24 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 B51AE3A6B2E; Fri, 9 Jan 2009 08:12:24 -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 1C9AB3A6B2C for ; Fri, 9 Jan 2009 08:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 FIZ8IQLspxo4 for ; Fri, 9 Jan 2009 08:12:23 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id C2E143A6A70 for ; Fri, 9 Jan 2009 08:12:20 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSWd3VmhQf1GUS4XLqDQRnVx13cl/lB+j@postini.com; Fri, 09 Jan 2009 08:12:09 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.336.0; Fri, 9 Jan 2009 08:10:14 -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); Fri, 9 Jan 2009 08:10:13 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 08:10:13 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jan 2009 08:10:13 -0800 Received: from scarlson-lt.jnpr.net (scarlson-lt.jnpr.net [172.24.234.18] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n09GACM94960; Fri, 9 Jan 2009 08:10:12 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Richard Ogier In-Reply-To: <49663239.5050103@earthlink.net> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 9 Jan 2009 11:10:12 -0500 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <49658039.1090204@earthlink.net> <1D5D3DA2-0CE6-47AF-AABD-2DAD113EA1D9@juniper.net> <49663239.5050103@earthlink.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Jan 2009 16:10:13.0354 (UTC) FILETIME=[C0D224A0:01C97274] Cc: ospf@ietf.org, joakim.tjernlund@transmode.se Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 On Jan 8, 2009, at 12:04 PM, Richard Ogier wrote: > > I am assuming that a stub link is always required for *numbered* > point-to-point links (as per RFC 2328), and is optional for > *unnumbered* links (my suggestion). Hm, I guess a further ambiguity in the spec is the use of the word "option" in clause 12.4.1.1 (combined with the lower-case "should".) I always read "should" as MUST and "option" as a bullet point and implemented it as such. English prose is a lousy way to specify a protocol without linguistic ground rules (eventually added by the IETF, but long after OSPF was created.) But as I noted in my last email, I finally copped a clue and realized that Option 1 isn't required for the protocol to work. Nor, for that matter, is option 2--since the link is point-to-point between two routers, there are no hosts there, and thus nothing that "must" be routed to, so the subnet route is pretty uninteresting. But for that matter, footnote 2 is equally uninteresting from the standpoint of routing to hosts. The language here seems to be as ambiguous as all the rest; it says that the address "will then be advertised" which implies a normative clause elsewhere in the spec requiring such, but I don't see it. Similarly, the text Richard quotes on page 15 is an introductory description of something for which there appears to be no normative text requiring it. All of this gets back to the metaproblem, which is that the OSPF spec is incredibly muddled with regard to what is normative and what is not. Although it may not be codified anywhere, the point of normative text in a spec is to ensure proper operation and interoperability of the protocol. The fact is (contrary to my assertions earlier) that there is no requirement for *any* router address or point-to-point subnet to be announced in the protocol in order to ensure proper operation (providing reachability to hosts) or interoperability, with the sole exception of virtual link endpoints (which are accounted for in type 4 links anyhow.) As being able to reach the router is rather useful, an implementation has an interest in advertising at least one way of reaching a router, but that is not truly necessary, and a router that did none of this would work just fine (assuming you had an out-of-band configuration mechanism, which is probably a lot safer security-wise, but that's a separate rant.) But I withdraw my earlier rantings; in fact none of this stub route stuff matters for interoperability and none of it should be normative. A polite suggestion along the lines of "if you want to be able to reach the router in-band you'll need to advertise something to make that happen" as non-normative text would suffice. Cleaning up the OSPF spec to make it rigorous along these lines is a thankless task that isn't likely to happen. There have been a number of willful veerings from the spec on things that are unambiguously normative but stupid (like the 5 second rule for LSA generation *and* reception, and the 30 minute refresh interval) and can be ignored without impacting interoperability. I'll shut up now... --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 9 13:37:38 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 6951C3A685E; Fri, 9 Jan 2009 13:37:38 -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 128C13A685E for ; Fri, 9 Jan 2009 13:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HELO_EQ_SE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-EinWZhp7oD for ; Fri, 9 Jan 2009 13:37:36 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 985A53A63D2 for ; Fri, 9 Jan 2009 13:37:34 -0800 (PST) Received: from jockexp ([192.168.105.18]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Jan 2009 22:37:11 +0100 From: "Joakim Tjernlund" To: "'Dave Katz'" References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <496664BB.7030807@earthlink.net> <01b101c971e7$1a322dd0$4e968970$@Tjernlund@transmode.se> <49669745.6040104@earthlink.net> <1231494401.5831.28.camel@gentoo-jocke.transmode.se> In-Reply-To: Date: Fri, 9 Jan 2009 22:37:00 +0100 Message-ID: <024201c972a2$69954b30$3cbfe190$@Tjernlund@transmode.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclycN8ASDCCGmAATsu3Vp4L3Xy3NwAMK1fQ Content-Language: sv X-OriginalArrivalTime: 09 Jan 2009 21:37:11.0856 (UTC) FILETIME=[6E5BFB00:01C972A2] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: den 9 januari 2009 16:40 > To: joakim.tjernlund@transmode.se > Cc: Richard Ogier; ospf@ietf.org > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > > On Jan 9, 2009, at 4:46 AM, Joakim Tjernlund wrote: > > > > If I understand Dave correctly, the host route announced must be > > the IP address used by the unnumbered PtoP links, I don't understand > > this requirement though so I hope Dave is wrong. > > Actually, I'm wrong. Most (probably all) implementations don't route > their OSPF packets, but blast them out interfaces directly. I got > hung up on the fact that, without such an announcement, nobody could > route to that source address, but it doesn't matter (typically). Mea > culpa. OK, thanks for this. > > I believe that if one pull the cable from an Ethernet interface, the > > router should turn the announced subnet into a host route of type Loop > > back instead, this is actually my next point I want to discuss > > so any comments on this would be much appreciated. > > And that's an implementation decision that should be outside the scope > of the spec. Could you comment on if you think a loopback host route is the right think to announce or if once should use a plain stub host route? Can you see any downsides announcing some type of host route in this case? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From kbrunsonm@alixpartners.com Fri Jan 9 18:05:37 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFF73A6930 for ; Fri, 9 Jan 2009 18:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.647 X-Spam-Level: X-Spam-Status: No, score=-23.647 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] 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 8etmv-FMyAKt for ; Fri, 9 Jan 2009 18:05:37 -0800 (PST) Received: from 201-92-64-159.dsl.telesp.net.br (201-92-64-159.dsl.telesp.net.br [201.92.64.159]) by core3.amsl.com (Postfix) with SMTP id 421933A63D3 for ; Fri, 9 Jan 2009 18:05:35 -0800 (PST) To: Subject: RE: Message 97238 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110020536.421933A63D3@core3.amsl.com> Date: Fri, 9 Jan 2009 18:05:35 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 06885
From ospf-bounces@ietf.org Sat Jan 10 06:56: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 5CACE28C10C; Sat, 10 Jan 2009 06:56: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 918633A689B for ; Sat, 10 Jan 2009 06:56: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 X8Iv0pbgs7T5 for ; Sat, 10 Jan 2009 06:56:52 -0800 (PST) Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by core3.amsl.com (Postfix) with ESMTP id E0ACC3A67D7 for ; Sat, 10 Jan 2009 06:56:52 -0800 (PST) Received: from headquarters.firelightfoundation.org (adsl-67-114-21-85.dsl.pltn13.pacbell.net [67.114.21.85]) by mail.cruzio.com with ESMTP id n0AEuSvw084575; Sat, 10 Jan 2009 06:56:28 -0800 (PST) Received: from [10.10.73.62] (ip201-130.digitalrealm.net [216.144.201.130]) by headquarters.firelightfoundation.org (Postfix) with ESMTP id DE9C2EFFAD; Sat, 10 Jan 2009 06:56:21 -0800 (PST) Message-Id: From: Dave Katz To: Joakim Tjernlund In-Reply-To: <024201c972a2$69954b30$3cbfe190$@Tjernlund@transmode.se> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 10 Jan 2009 09:56:19 -0500 References: <001701c9701a$73c8f460$5b5add20$@Tjernlund@transmode.se> <002001c9702c$f007ba40$d0172ec0$@Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506@juniper.net> <002301c97031$206e0780$614a1680$@Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B@juniper.net> <002c01c97044$713b2b80$53b18280$@Tjernlund@transmode.se> <1231337929.21348.177.camel@gentoo-jocke.transmode.se> <496664BB.7030807@earthlink.net> <01b101c971e7$1a322dd0$4e968970$@Tjernlund@transmode.se> <49669745.6040104@earthlink.net> <1231494401.5831.28.camel@gentoo-jocke.transmode.se> <024201c972a2$69954b30$3cbfe190$@Tjernlund@transmode.se> X-Mailer: Apple Mail (2.930.3) Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 On Jan 9, 2009, at 4:37 PM, Joakim Tjernlund wrote: >> >>> I believe that if one pull the cable from an Ethernet interface, the >>> router should turn the announced subnet into a host route of type >>> Loop >>> back instead, this is actually my next point I want to discuss >>> so any comments on this would be much appreciated. >> >> And that's an implementation decision that should be outside the >> scope >> of the spec. > > Could you comment on if you think a loopback host route is the > right think to announce or if once should use a plain stub host route? The common thing is to create a loopback address that's independent of any interface, and to advertise that as a stub. It provides a stable address over the long term, as interfaces and topology changes come and go. In my original implementation, the Juniper box would automatically assign the lo0 address, if present, as the router ID, and in addition advertise a stub route to it. Not sure if this is still the case (as I mentioned, some folks started complaining about this.) This was also the endpoint address for BGP connections, which is the other primary use of routing to routers outside of management. > > > Can you see any downsides announcing some type of host route > in this case? None that I know of; it's pretty common. It is one more link in the LSA, but if one more link creates performance problems, then the network/implementation has much bigger issues. --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From jerry@adopt-now.com Sat Jan 10 14:02:10 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BB53A689D for ; Sat, 10 Jan 2009 14:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.487 X-Spam-Level: X-Spam-Status: No, score=-13.487 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 wKQvfyQFmKDU for ; Sat, 10 Jan 2009 14:02:09 -0800 (PST) Received: from ab6x.net (unknown [87.13.203.58]) by core3.amsl.com (Postfix) with SMTP id 72EFF3A6945 for ; Sat, 10 Jan 2009 14:02:08 -0800 (PST) To: Subject: RE: Message 63565 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110220208.72EFF3A6945@core3.amsl.com> Date: Sat, 10 Jan 2009 14:02:08 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 89956
From oticavisao@amazoncoop.com.br Mon Jan 12 00:57:55 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF6928C2DC for ; Mon, 12 Jan 2009 00:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.241 X-Spam-Level: X-Spam-Status: No, score=-24.241 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_IS_SMALL6=0.556, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 HSPr1L-1hbcR for ; Mon, 12 Jan 2009 00:57:54 -0800 (PST) Received: from aget.gr (unknown [78.128.4.242]) by core3.amsl.com (Postfix) with SMTP id 96E7328C2DD for ; Mon, 12 Jan 2009 00:57:52 -0800 (PST) To: Subject: Re: Order status 94741 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112085753.96E7328C2DD@core3.amsl.com> Date: Mon, 12 Jan 2009 00:57:52 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 63913
From hassan.dasuki@hotmail.fr Mon Jan 12 10:39:55 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121E83A6358 for ; Mon, 12 Jan 2009 10:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.701 X-Spam-Level: ** X-Spam-Status: No, score=2.701 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_FRIEND=2.699, 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 6h-NjF5spjIJ for ; Mon, 12 Jan 2009 10:39:54 -0800 (PST) Received: from relay.clickability.com (relay.clickability.com [208.184.224.72]) by core3.amsl.com (Postfix) with SMTP id 220A73A67EC for ; Mon, 12 Jan 2009 10:39:54 -0800 (PST) Received: (qmail 6987 invoked by uid 555); 12 Jan 2009 18:39:40 -0000 Received: from 192.168.10.25 by mailer01.clickability.com (envelope-from , uid 303) with qmail-scanner-1.25st (spamassassin: 3.0.4. perlscan: 1.25st. Clear:RC:0(192.168.10.25):SA:0(-1.8/5.0):. Processed in 7.398677 secs); 12 Jan 2009 18:39:40 -0000 Received: from sj-c14-r2-u4.sj.clickability.com (HELO relay.clickability.com) (192.168.10.25) by mailer01.clickability.com with SMTP; 12 Jan 2009 18:39:30 -0000 Received: (qmail 16718 invoked from network); 12 Jan 2009 18:39:29 -0000 Received: from localhost (HELO relay.clickability.com) (127.0.0.1) by localhost with SMTP; 12 Jan 2009 18:39:29 -0000 Message-ID: <1245277499.1837551231785569378.JavaMail.tomcat@localhost> Date: Mon, 12 Jan 2009 10:39:29 -0800 (PST) From: "h.dasuki" To: hassan.dasuki@hotmail.fr Subject: Please Assist me. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_183755_1420783956.1231785569377" X-Mailer: sendhtml ------=_Part_183755_1420783956.1231785569377 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: INLINE *Please note, the sender's email address has not been verified. Dear friend I am a banker in groupe bank of Africa I contact you now on a business deal of us US$10,5m, to be transfered to your account.The depositor of the said fund died with his family in a plane crash. He died unfortunately leaving nobody for the claim as next of kin. If we make this claim, you will have 40% and I will have 60%. I need your reply as to give you the full details on how we shall do it. Reply and call me immediately. Mr.Hassan Dasuki +226 76 61 65 94 ******************** If you are having trouble with any of the links in this message, or if the URL's are not appearing as links, please follow the instructions at the bottom of this email. Title: When All You Know is an E-mail Address... Copy and paste the following into your Web browser to access the sent link: http://www.emailthis.clickability.com/et/emailThis?clickMap=viewThis&etMailToID=680963263&pt=Y Copy and paste the following into your Web browser to SAVE THIS link: http://www.savethis.clickability.com/st/saveThisPopupApp?clickMap=saveFromET&partnerID=97646&etMailToID=680963263&pt=Y Copy and paste the following into your Web browser to forward this link: http://www.emailthis.clickability.com/et/emailThis?clickMap=forward&etMailToID=680963263&partnerID=97646&pt=Y ******************** Email pages from any Web site you visit - add the EMAIL THIS button to your browser, copy and paste the following into your Web browser: http://www.emailthis.clickability.com/et/emailThis?clickMap=browserButtons&pt=Y" ********************* Instructions: ----------------------------------------- If your e-mail program doesn't recognize Web addresses: 1. With your mouse, highlight the Web Address above. Be sure to highlight the entire Web address, even if it spans more than one line in your email. 2. Select Copy from the Edit menu at the top of your screen. 3. Launch your Web browser. 4. Paste the address into your Web browser by selecting Paste from the Edit menu. 5. Click Go or press Enter or Return on your keyboard. ******************** ------=_Part_183755_1420783956.1231785569377 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: INLINE EMAIL THIS Email
 
Multichannel Merchant  
 * Please note, the sender's email address has not been verified.
   
 
Dear friend
I am a banker in groupe bank of Africa
I contact you now on a business deal of us US$10,5m, to be transfered to your
account.The depositor of the said fund died with his family in a plane crash.
He died unfortunately leaving nobody for the claim as next of kin. If we make
this claim, you will have 40% and I will have 60%. I need your reply as to
give you the full details on how we shall do it. Reply and call me immediately.
Mr.Hassan Dasuki
+226 76 61 65 94



  
   
   
  Click the following to access the sent link:
   
 
When All You Know is an E-mail Address...*
     
 
 
  SAVE THIS link FORWARD THIS link
 
 
   
Get your EMAIL THIS Browser Button and use it to email content from any Web site. Click here for more information.
   
   
  *This article can also be accessed if you copy and paste the entire address below into your web browser.
http://multichannelmerchant.com/crosschannel/lists/rosen_e-mail_01082007

------=_Part_183755_1420783956.1231785569377-- From melmaga@alt4u.com Mon Jan 12 11:19:56 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA033A6A40 for ; Mon, 12 Jan 2009 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.673 X-Spam-Level: X-Spam-Status: No, score=-7.673 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 pSmATQF9ISbc for ; Mon, 12 Jan 2009 11:19:56 -0800 (PST) Received: from 77-253-198-153.adsl.inetia.pl (77-253-198-153.adsl.inetia.pl [77.253.198.153]) by core3.amsl.com (Postfix) with SMTP id 428E33A68F7 for ; Mon, 12 Jan 2009 11:19:52 -0800 (PST) To: Subject: Your order 28680 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112191953.428E33A68F7@core3.amsl.com> Date: Mon, 12 Jan 2009 11:19:52 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 96406
From kh_chan@afcd.gov.hk Tue Jan 13 01:07:02 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248E43A6851 for ; Tue, 13 Jan 2009 01:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.442 X-Spam-Level: X-Spam-Status: No, score=-21.442 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 3J9QdNft5-FN for ; Tue, 13 Jan 2009 01:07:01 -0800 (PST) Received: from host92-37-dynamic.7-79-r.retail.telecomitalia.it (host92-37-dynamic.7-79-r.retail.telecomitalia.it [79.7.37.92]) by core3.amsl.com (Postfix) with SMTP id 22CDC3A677C for ; Tue, 13 Jan 2009 01:06:57 -0800 (PST) To: Subject: Your order 70665 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113090700.22CDC3A677C@core3.amsl.com> Date: Tue, 13 Jan 2009 01:06:57 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 79946
From necmo@ab.fem.jp Tue Jan 13 17:10:07 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFB33A6A19 for ; Tue, 13 Jan 2009 17:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.69 X-Spam-Level: X-Spam-Status: No, score=-18.69 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 Fh9wf9Sqb5ao for ; Tue, 13 Jan 2009 17:10:07 -0800 (PST) Received: from 201-3-38-158.cbace702.dsl.brasiltelecom.net.br (201-25-75-137.cbace702.dsl.brasiltelecom.net.br [201.25.75.137]) by core3.amsl.com (Postfix) with SMTP id 15AE83A69FD for ; Tue, 13 Jan 2009 17:10:00 -0800 (PST) To: Subject: Re: admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114011003.15AE83A69FD@core3.amsl.com> Date: Tue, 13 Jan 2009 17:10:00 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 88695
From ospf-bounces@ietf.org Wed Jan 14 06:56:57 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 3C75228C11E; Wed, 14 Jan 2009 06:56:57 -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 85B973A69D3 for ; Wed, 14 Jan 2009 06:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=1.165, 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 N4SznJpCsYeM for ; Wed, 14 Jan 2009 06:56:54 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id C87743A69EC for ; Wed, 14 Jan 2009 06:56:44 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2009 15:56:17 +0100 To: "Dave Katz" MIME-Version: 1.0 X-KeepSent: 18F77276:71CCA591-C125753E:00516B6D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Wed, 14 Jan 2009 15:55:58 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-14 15:56:28, Serialize complete at 2009-01-14 15:56:28 X-OriginalArrivalTime: 14 Jan 2009 14:56:18.0068 (UTC) FILETIME=[413FF540:01C97658] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 "Dave Katz" wrote on 09/01/2009 16:40:25: > To: Joakim Tjernlund/Transmode@TM > Cc: "Richard Ogier" , ospf@ietf.org > Date: 09/01/2009 16:42 > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > On Jan 9, 2009, at 4:46 AM, Joakim Tjernlund wrote: > > > > I believe that if one pull the cable from an Ethernet interface, the > > router should turn the announced subnet into a host route of type Loop > > back instead, this is actually my next point I want to discuss > > so any comments on this would be much appreciated. > > And that's an implementation decision that should be outside the scope > of the spec. > > I'll fall on my sword here and say that there is no fundamental need > to announce any router address by anybody unless the router wants to > be reachable (a useful thing indeed, but not necessary to the > functioning of the protocol.) > > --Dave So I tried to announce a host route via the loopback interface: In bash: ifconfig lo:0 192.168.1.16 netmask 255.255.255.255 Then the only thing I could think of to announce it in OSPF was: configure terminal router ospf network 192.162.1.16/32 area 0 But this will only work for one area. Any ideas on how to announce a particular host route in all areas? Can you do that in Juniper? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 14 08:36:12 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 1D27728C1C6; Wed, 14 Jan 2009 08:36:12 -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 B858E28C1BF for ; Wed, 14 Jan 2009 08:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 MIUjRNwb+vgv for ; Wed, 14 Jan 2009 08:36:10 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id E9B2D28C1B6 for ; Wed, 14 Jan 2009 08:36:07 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSW4UY0RZS0lSR6W864i0tWdJm97MHFxC@postini.com; Wed, 14 Jan 2009 08:35:55 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.336.0; Wed, 14 Jan 2009 08:30:49 -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); Wed, 14 Jan 2009 08:30:49 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 08:30:49 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 08:30:48 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0EGUmM67881; Wed, 14 Jan 2009 08:30:48 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Joakim Tjernlund In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 14 Jan 2009 09:30:47 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 Jan 2009 16:30:48.0998 (UTC) FILETIME=[75633460:01C97665] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 On Jan 14, 2009, at 7:55 AM, Joakim Tjernlund wrote: > > So I tried to announce a host route via the loopback interface: > In bash: > ifconfig lo:0 192.168.1.16 netmask 255.255.255.255 > > Then the only thing I could think of to announce it in OSPF was: > configure terminal > router ospf > network 192.162.1.16/32 area 0 > > But this will only work for one area. > Any ideas on how to announce a particular host route in > all areas? > Can you do that in Juniper? Seems like all implementations should generate a summary at the ABRs and announce them throughout, just like any other destination in the area. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From manojkr2@afo.net Wed Jan 14 09:34:24 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3563A69B8 for ; Wed, 14 Jan 2009 09:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.804 X-Spam-Level: X-Spam-Status: No, score=-14.804 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 OIr9WF-9lLl3 for ; Wed, 14 Jan 2009 09:34:24 -0800 (PST) Received: from afo.net (unknown [88.233.136.242]) by core3.amsl.com (Postfix) with SMTP id 1C5B03A68D6 for ; Wed, 14 Jan 2009 09:34:20 -0800 (PST) To: Subject: Re: admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114173422.1C5B03A68D6@core3.amsl.com> Date: Wed, 14 Jan 2009 09:34:20 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 50487
From ospf-bounces@ietf.org Wed Jan 14 10:00: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 D1D1E3A6A2C; Wed, 14 Jan 2009 10:00: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 90F863A6A2C for ; Wed, 14 Jan 2009 10:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=1.092, 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 PQqES8Dg7YRA for ; Wed, 14 Jan 2009 10:00:13 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 7308F3A6A1C for ; Wed, 14 Jan 2009 10:00:12 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2009 18:59:46 +0100 In-Reply-To: References: To: Dave Katz MIME-Version: 1.0 X-KeepSent: 4EC6CFF5:1A951DA2-C125753E:00620F20; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Wed, 14 Jan 2009 18:59:56 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-14 18:59:56, Serialize complete at 2009-01-14 18:59:56 X-OriginalArrivalTime: 14 Jan 2009 17:59:46.0193 (UTC) FILETIME=[E29A8810:01C97671] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 Dave Katz wrote on 14/01/2009 17:30:47: > To: Joakim Tjernlund > Cc: "Richard Ogier" , ospf@ietf.org > Date: 14/01/2009 17:35 > Subject: Re: [OSPF] Unnumbered PtoP router LSA question. > > > On Jan 14, 2009, at 7:55 AM, Joakim Tjernlund wrote: > > > > So I tried to announce a host route via the loopback interface: > > In bash: > > ifconfig lo:0 192.168.1.16 netmask 255.255.255.255 > > > > Then the only thing I could think of to announce it in OSPF was: > > configure terminal > > router ospf > > network 192.162.1.16/32 area 0 > > > > But this will only work for one area. > > Any ideas on how to announce a particular host route in > > all areas? > > Can you do that in Juniper? > > Seems like all implementations should generate a summary at the ABRs > and announce them throughout, just like any other destination in the > area. I found that I could specify on address to the passive-interface command: passive-interface lo 192.168.1.16 and that appears to work somewhat, but the semantics of the passive command is a bit unclear to me. The docs suggest that this should be enough add an entry in the router LSA but it isn't unless I also do a "network 192.162.1.16/32 area 0" too. Removing the network: "no network 192.162.1.16/32 area 0" doesn't remove anything from the router LSA. I smell a bug a two. Should the passive-interface command alone be enough to announce a host route in the router LSA? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From mkarapinar@aloeveraankara.com Wed Jan 14 10:22:57 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C883A69C2 for ; Wed, 14 Jan 2009 10:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 c8aE7EXsEBFT for ; Wed, 14 Jan 2009 10:22:50 -0800 (PST) Received: from adsl-070-154-154-060.sip.lft.bellsouth.net (adsl-070-154-154-060.sip.lft.bellsouth.net [70.154.154.60]) by core3.amsl.com (Postfix) with SMTP id A39313A69A9 for ; Wed, 14 Jan 2009 10:22:48 -0800 (PST) To: Subject: Re: admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114182249.A39313A69A9@core3.amsl.com> Date: Wed, 14 Jan 2009 10:22:48 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 46536
From kronhard@alkon-pc.de Wed Jan 14 12:55:58 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128ED3A67F9 for ; Wed, 14 Jan 2009 12:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.994 X-Spam-Level: X-Spam-Status: No, score=-44.994 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RO=1.235, HOST_EQ_RO=0.904, HOST_EQ_STATICB=1.372, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] 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 7B1h+ppa9pGp for ; Wed, 14 Jan 2009 12:55:52 -0800 (PST) Received: from static-89-37-113-26.cj.maxnet.ro (static-89-37-113-26.cj.maxnet.ro [89.37.113.26]) by core3.amsl.com (Postfix) with SMTP id 5855C28C0EC for ; Wed, 14 Jan 2009 12:55:50 -0800 (PST) To: Subject: from admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114205551.5855C28C0EC@core3.amsl.com> Date: Wed, 14 Jan 2009 12:55:50 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 78016
From lcmoving@ampam.com Wed Jan 14 13:41:07 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E45228C1C4 for ; Wed, 14 Jan 2009 13:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.666 X-Spam-Level: X-Spam-Status: No, score=-43.666 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_UK=1.749, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] 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 vChrqysv+HTz for ; Wed, 14 Jan 2009 13:41:03 -0800 (PST) Received: from allianceweb.co.uk (unknown [189.82.64.185]) by core3.amsl.com (Postfix) with SMTP id 9D0B53A67F9 for ; Wed, 14 Jan 2009 13:40:59 -0800 (PST) To: Subject: Re: admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114214100.9D0B53A67F9@core3.amsl.com> Date: Wed, 14 Jan 2009 13:40:59 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 94523
From ospf-bounces@ietf.org Wed Jan 14 18:27:51 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 2A9F53A6AAE; Wed, 14 Jan 2009 18:27:51 -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 4E1D33A6ACD for ; Wed, 14 Jan 2009 18:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 NAJWQw8R3xoo for ; Wed, 14 Jan 2009 18:27:48 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 77BA23A6863 for ; Wed, 14 Jan 2009 18:27:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSW6fEgLSs8lcbV822GUA4DMEp1HyN+3j@postini.com; Wed, 14 Jan 2009 18:27: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.336.0; Wed, 14 Jan 2009 18:23:04 -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); Wed, 14 Jan 2009 18:23:04 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 18:23:03 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 18:23:03 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0F2N0M54761; Wed, 14 Jan 2009 18:23:01 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Joakim Tjernlund In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 14 Jan 2009 19:22:59 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 15 Jan 2009 02:23:03.0606 (UTC) FILETIME=[31AA1560:01C976B8] Cc: ospf@ietf.org Subject: Re: [OSPF] Unnumbered PtoP router LSA 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 On Jan 14, 2009, at 10:59 AM, Joakim Tjernlund wrote: >> >> Seems like all implementations should generate a summary at the ABRs >> and announce them throughout, just like any other destination in the >> area. > > I found that I could specify on address to the passive-interface > command: > passive-interface lo 192.168.1.16 > and that appears to work somewhat, but the semantics of the passive > command is a bit unclear to me. The docs suggest that this should > be enough add an entry in the router LSA but it isn't unless I also > do a "network 192.162.1.16/32 area 0" too. Removing the network: > "no network 192.162.1.16/32 area 0" doesn't remove anything from the > router > LSA. I smell a bug a two. Should the passive-interface command alone > be enough to announce a host route in the router LSA? This is vendor-specific and probably does not belong on this list... --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From larissa.maher@accountancyservices.com.au Thu Jan 15 04:36:13 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591773A690B for ; Thu, 15 Jan 2009 04:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 6zT0oWd0lccF for ; Thu, 15 Jan 2009 04:36:09 -0800 (PST) Received: from ppp-124-120-172-8.revip2.asianet.co.th (ppp-124-120-172-8.revip2.asianet.co.th [124.120.172.8]) by core3.amsl.com (Postfix) with SMTP id B6C1D3A67A1 for ; Thu, 15 Jan 2009 04:36:00 -0800 (PST) To: Subject: from admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115123603.B6C1D3A67A1@core3.amsl.com> Date: Thu, 15 Jan 2009 04:36:00 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 15872
From ospf-bounces@ietf.org Thu Jan 15 08:08:32 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 7A9C33A68EF; Thu, 15 Jan 2009 08:08:32 -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 A23D13A68EF for ; Thu, 15 Jan 2009 08:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 2H3pUZgOPZNL for ; Thu, 15 Jan 2009 08:08:30 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id D9F7F3A67AF for ; Thu, 15 Jan 2009 08:08:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 47A9A7D097F for ; Thu, 15 Jan 2009 08:08:16 -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 07219-06 for ; Thu, 15 Jan 2009 08:08:16 -0800 (PST) Received: from [IPv6???1] (lxlogin-4-300.redback.com [155.53.12.219]) by prattle.redback.com (Postfix) with ESMTP id E03EF7D0981 for ; Thu, 15 Jan 2009 08:08:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: References: Message-Id: From: Acee Lindem Date: Thu, 15 Jan 2009 11:08:16 -0500 To: OSPF List X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] Fwd: RFC 5378 and Draft Submissions 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 FYI - Luckily, we got a number of respin RFCs through the process prior to RFC 5378. I suggest all draft authors read RFC 5378 and determine whether you'll have any problems 1) granting rights to the IETF 2) getting all authors to grant rights. Thanks, Acee ---------- Forwarded message ---------- From: Eric Rescorla Date: Wed, Jan 14, 2009 at 9:03 PM Subject: RFC 5378 and Draft Submissions To: tls@ietf.org IETF Chair Russ Housley has asked WG chairs to apprise their WGs of the following information. If you've been following the IETF mailing list, you may be aware of the ongoing discussion about the impact of RFC 5378 on revised draft submissions. Briefly, RFC 5378 requires Contributors to grant a more expansive set of rights than were granted by RFC 3978, and 4748. If you are submitting a document which contains text contributed by others prior to the publication of RFC 5378 you may need to obtain additional rights from the copyright holders of that text in order to contribute under the 5378 terms. The IESG and the IETF Trustees are working to resolve those issues (see http://trustee.ietf.org/docs/Background-to-Draft-Update-to-IETF-Trust- Legal-Provisions.txt). However, at present I would advise care prior to submitting any draft which contains material derived from an RFC, draft, or mailing list message published prior to November 10, 2008. Speaking personally, I have chosen not to submit new versions of most of my drafts until matters are resolved. Please take any general discussion of RFC 5378 to ietf@ietf.org -Ekr [As WG Chair] _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From mbunch_42@aguiabranca.com.br Thu Jan 15 10:36:33 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968673A6774 for ; Thu, 15 Jan 2009 10:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.293 X-Spam-Level: X-Spam-Status: No, score=-11.293 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 fN8FLAVIYbbU for ; Thu, 15 Jan 2009 10:36:31 -0800 (PST) Received: from 85-18-78-60.ip.fastwebnet.it (85-18-78-60.ip.fastwebnet.it [85.18.78.60]) by core3.amsl.com (Postfix) with SMTP id 1B1E33A6842 for ; Thu, 15 Jan 2009 10:36:29 -0800 (PST) To: Subject: News from Microsoft From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115183630.1B1E33A6842@core3.amsl.com> Date: Thu, 15 Jan 2009 10:36:29 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 18200
From jherrera@ae.com Thu Jan 15 22:14:33 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5387B3A6803 for ; Thu, 15 Jan 2009 22:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.533 X-Spam-Level: X-Spam-Status: No, score=-7.533 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 xQPM-nE+hWpx for ; Thu, 15 Jan 2009 22:14:31 -0800 (PST) Received: from pool-173-70-53-18.nwrknj.fios.verizon.net (pool-173-70-53-68.nwrknj.fios.verizon.net [173.70.53.68]) by core3.amsl.com (Postfix) with SMTP id BE94A3A67AA for ; Thu, 15 Jan 2009 22:14:30 -0800 (PST) To: Subject: News from Microsoft From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090116061430.BE94A3A67AA@core3.amsl.com> Date: Thu, 15 Jan 2009 22:14:30 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 90952
From ospf-bounces@ietf.org Sun Jan 18 05:36:45 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 8169428C0E9; Sun, 18 Jan 2009 05:36:45 -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 268F128C0E9 for ; Sun, 18 Jan 2009 05:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.014 X-Spam-Level: X-Spam-Status: No, score=-0.014 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_40=-0.185, 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 rhiWPiGvbaWV for ; Sun, 18 Jan 2009 05:36:40 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 2988F3A685D for ; Sun, 18 Jan 2009 05:36:38 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Sun, 18 Jan 2009 14:36:17 +0100 Sensitivity: MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Joakim Tjernlund To: ospf@ietf.org X-MIMETrack: MIME-CD by HTTP Server on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-18 14:36:12, MIME-CD complete at 2009-01-18 14:36:12, Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-18 14:36:12 Message-ID: Date: Sun, 18 Jan 2009 14:36:12 +0100 X-Mailer: Lotus Domino Web Server Release 8.0.2 August 07, 2008 X-OriginalArrivalTime: 18 Jan 2009 13:36:17.0963 (UTC) FILETIME=[BDD10FB0:01C97971] Subject: [OSPF] Adding host routes in the router LSA 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 I RFC 2328, last in chap "12.4.1. Router-LSAs" one can read: After consideration of all the router interfaces, host links are added to the router-LSA by examining the list of attached hosts belonging to Area A. A host route is represented as a Type 3 link (stub network) whose Link ID is the host's IP address, Link Data is the mask of all ones (0xffffffff), and cost the host's configured cost (see Section C.7). If I read this correctly one should add in the router LSA all local interfaces belonging to the area as host routes. For example if eth0 is included in the area and have IP 192.168.1.2 and a /24 subnet one should add two stub routes: 192.168.1.0/24 and a 192.168.1.2/32 to the router LSA. To me this also suggests that the host route should be announced even if the ethernet cable is pulled(i.e the interface is UP but not RUNNING). I guess unnumbered interfaces should be omitted as these doesn't have an IP address? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Jan 18 10:43:37 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 BE2233A68EF; Sun, 18 Jan 2009 10:43:37 -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 5F08F3A68EF for ; Sun, 18 Jan 2009 10:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 3muc5DekNyeW for ; Sun, 18 Jan 2009 10:43:35 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 91EB13A679C for ; Sun, 18 Jan 2009 10:43:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BB660A97236; Sun, 18 Jan 2009 10:43:19 -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 12309-06; Sun, 18 Jan 2009 10:43:19 -0800 (PST) Received: from [IPv6???1] (lxlogin-4-300.redback.com [155.53.12.219]) by prattle.redback.com (Postfix) with ESMTP id 26905A97235; Sun, 18 Jan 2009 10:43:18 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) X-Priority: 3 (Normal) Message-Id: <9F13E6B4-3820-4146-9D72-C364A69013DE@redback.com> From: Acee Lindem Date: Sun, 18 Jan 2009 13:43:19 -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] Adding host routes in the router LSA 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 Jan 18, 2009, at 8:36 AM, Joakim Tjernlund wrote: > > I RFC 2328, last in chap "12.4.1. Router-LSAs" one can read: > After consideration of all the router interfaces, host links > are added to the router-LSA by examining the list of > attached hosts belonging to Area A. A host route is > represented as a Type 3 link (stub network) whose Link ID is > the host's IP address, Link Data is the mask of all ones > (0xffffffff), and cost the host's configured cost (see > Section C.7). > > If I read this correctly one should add in the router LSA all local > interfaces belonging > to the area as host routes. For example if eth0 is included in the > area and > have IP 192.168.1.2 and a /24 subnet one should add two stub routes: > 192.168.1.0/24 and a 192.168.1.2/32 to the router LSA. To me this also > suggests > that the host route should be announced even if the ethernet cable is > pulled(i.e the > interface is UP but not RUNNING). No - you've misinterpreted RFC 2328. This is refers to "Hosts attached directly to routers .." as described in section 2.1. Based on the specification, these are configured (refer to section C.7). I've never worked on an implementation that supported these directly attached hosts as described in RFC 2328. > > I guess unnumbered interfaces should be omitted as these doesn't > have an IP > address? No. I think we've already covered this :^) 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 mariana.simonl@alico.com.ar Sun Jan 18 11:22:58 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBD53A6823 for ; Sun, 18 Jan 2009 11:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.196 X-Spam-Level: X-Spam-Status: No, score=-18.196 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 2p8r5fEuFPIO for ; Sun, 18 Jan 2009 11:22:57 -0800 (PST) Received: from dynamic.rabat2-124-236-12-196.wanamaroc.com (dynamic.rabat2-124-236-12-196.wanamaroc.com [196.12.236.124]) by core3.amsl.com (Postfix) with SMTP id 8C8F83A68FF for ; Sun, 18 Jan 2009 11:22:46 -0800 (PST) To: Subject: Re: Pfizer Admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090118192248.8C8F83A68FF@core3.amsl.com> Date: Sun, 18 Jan 2009 11:22:46 -0800 (PST)
January 16, 2009 | "SPECIAL OFFERS"-Pfizer Company!




Contact: Email Administrator, Pfizer World Headquarters 068 E. 42nd Street New York, NY 43860
® 2001-2009 Pfizer Inc. All rights reserved!
Pfizer is a licensee of the TRUSTe Privacy Program!, click here.

» Help  »Advertise  »Terms of Service  »Privacy Policy
From ospf-bounces@ietf.org Sun Jan 18 11:30:02 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 D27753A68FF; Sun, 18 Jan 2009 11:30:02 -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 C97EA3A68FF for ; Sun, 18 Jan 2009 11:30:01 -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 SvAywVS051w2 for ; Sun, 18 Jan 2009 11:30:01 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 93AD63A6823 for ; Sun, 18 Jan 2009 11:30:00 -0800 (PST) Received: by bwz14 with SMTP id 14so7331260bwz.13 for ; Sun, 18 Jan 2009 11:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oyDt8g2LDvVc0MwkgEj+95TXmZKQW30k62Fd0jF62AM=; b=nwlmc0jIKydTjtQNymm+rhEBqteLGU2MKXn8L5crw6qnHufxkvORG1SVnaThW5vkDn nlF/GjPICVMYdJybl3mi7WUCgFqey0qvIvDMi+Oketjk6L0WYUuHDgqwwK9pQ80fW2+3 GBhhftJOHrZCXMRItKRMZ0oX1ulFpJp5RGNIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xUM1gj+imVTtHWTu+RtLN8Us+S3MSHfbET2sm6EfjfEUnhXBQ5wq3Q6Wq+xC/ZE5iR HaaWz5G7LUScbU2PMp/Z05iWcFTkC8iw8BjZvJAJMRIipqOcOUWyvci2VCamYucVZ22C PKvfb8FBc7biGaZdLYtdB3hsKkRFeTqnO/lB4= Received: by 10.181.49.3 with SMTP id b3mr1778439bkk.21.1232306982407; Sun, 18 Jan 2009 11:29:42 -0800 (PST) Received: by 10.180.214.5 with HTTP; Sun, 18 Jan 2009 11:29:42 -0800 (PST) Message-ID: <77ead0ec0901181129n29c43755g6863e064c3815d48@mail.gmail.com> Date: Sun, 18 Jan 2009 11:29:42 -0800 From: "Vishwas Manral" To: "Acee Lindem" In-Reply-To: <9F13E6B4-3820-4146-9D72-C364A69013DE@redback.com> MIME-Version: 1.0 Content-Disposition: inline References: <9F13E6B4-3820-4146-9D72-C364A69013DE@redback.com> Cc: ospf@ietf.org, Joakim Tjernlund Subject: Re: [OSPF] Adding host routes in the router LSA 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 Acee, >> I RFC 2328, last in chap "12.4.1. Router-LSAs" one can read: >> After consideration of all the router interfaces, host links >> are added to the router-LSA by examining the list of >> attached hosts belonging to Area A. A host route is >> represented as a Type 3 link (stub network) whose Link ID is >> the host's IP address, Link Data is the mask of all ones >> (0xffffffff), and cost the host's configured cost (see >> Section C.7). >> >> If I read this correctly one should add in the router LSA all local >> interfaces belonging >> to the area as host routes. For example if eth0 is included in the area >> and >> have IP 192.168.1.2 and a /24 subnet one should add two stub routes: >> 192.168.1.0/24 and a 192.168.1.2/32 to the router LSA. To me this also >> suggests >> that the host route should be announced even if the ethernet cable is >> pulled(i.e the >> interface is UP but not RUNNING). > > No - you've misinterpreted RFC 2328. This is refers to "Hosts attached > directly to routers .." as described in section 2.1. Based on the > specification, these are configured (refer to section C.7). I've never > worked on an implementation that supported these directly attached hosts as > described in RFC 2328. > I mostly agree with Acee. It clearly says 1 stub entry with /32 route. Another use of the host route could be to be able to give different paths to some critical machines compared to others (so even hosts directly connected over a network could be used). To add we (IPInfusion Inc) support the host route, so there is atleast 1 implementation. Maybe Zebra does the same too. I myself got a customer trying to use it. Thanks, Vishwas _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Jan 18 11:30: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 37E4F28C0F9; Sun, 18 Jan 2009 11:30: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 2865E28C0F9 for ; Sun, 18 Jan 2009 11:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=1.038, 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 4pHu3e1xWv3R for ; Sun, 18 Jan 2009 11:30:14 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 149D828C0E4 for ; Sun, 18 Jan 2009 11:30:13 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Sun, 18 Jan 2009 20:29:53 +0100 In-Reply-To: <9F13E6B4-3820-4146-9D72-C364A69013DE@redback.com> References: <9F13E6B4-3820-4146-9D72-C364A69013DE@redback.com> To: Acee Lindem MIME-Version: 1.0 X-KeepSent: 4908D04A:FD454C5C-C1257542:006993EF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Sun, 18 Jan 2009 20:29:52 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-18 20:29:47, Serialize complete at 2009-01-18 20:29:47 X-OriginalArrivalTime: 18 Jan 2009 19:29:53.0553 (UTC) FILETIME=[234B3010:01C979A3] Cc: ospf@ietf.org Subject: Re: [OSPF] Adding host routes in the router LSA 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 18/01/2009 19:43:19: > Subject: Re: [OSPF] Adding host routes in the router LSA > > Hi Jocke, > > On Jan 18, 2009, at 8:36 AM, Joakim Tjernlund wrote: > > > > > I RFC 2328, last in chap "12.4.1. Router-LSAs" one can read: > > After consideration of all the router interfaces, host links > > are added to the router-LSA by examining the list of > > attached hosts belonging to Area A. A host route is > > represented as a Type 3 link (stub network) whose Link ID is > > the host's IP address, Link Data is the mask of all ones > > (0xffffffff), and cost the host's configured cost (see > > Section C.7). > > > > If I read this correctly one should add in the router LSA all local > > interfaces belonging > > to the area as host routes. For example if eth0 is included in the > > area and > > have IP 192.168.1.2 and a /24 subnet one should add two stub routes: > > 192.168.1.0/24 and a 192.168.1.2/32 to the router LSA. To me this also > > suggests > > that the host route should be announced even if the ethernet cable is > > pulled(i.e the > > interface is UP but not RUNNING). > > No - you've misinterpreted RFC 2328. This is refers to "Hosts > attached directly to routers .." as described in section 2.1. Based > on the specification, these are configured (refer to section C.7). > I've never worked on an implementation that supported these directly > attached hosts as described in RFC 2328. I see, thanks for clearing this up for me. > > > > > I guess unnumbered interfaces should be omitted as these doesn't > > have an IP > > address? > > No. I think we've already covered this :^) Yeah :) Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Jan 18 14:18:07 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 A9E213A6B56; Sun, 18 Jan 2009 14:18:07 -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 34F2128C0E4 for ; Sun, 18 Jan 2009 14:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.034 X-Spam-Level: X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=-0.317, 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 BryVhf7DBmVK for ; Sun, 18 Jan 2009 14:18:05 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 3274D3A67BD for ; Sun, 18 Jan 2009 14:18:04 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Sun, 18 Jan 2009 23:17:47 +0100 To: ospf@ietf.org MIME-Version: 1.0 X-KeepSent: 70BFB203:590F2A93-C1257542:0079B1B7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Sun, 18 Jan 2009 23:17:46 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-18 23:17:41, Serialize complete at 2009-01-18 23:17:41 X-OriginalArrivalTime: 18 Jan 2009 22:17:47.0922 (UTC) FILETIME=[9815E720:01C979BA] Subject: [OSPF] PtoP neighbour numbered or unnumbered? 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 I am trying to figure out a way to learn if the other end of a PtoP link is unnumberd or numbered. So far no luck. In this case I cannot look at the remote IP address of the PtoP link as it set in both cases. Ideas anyone? I am also trying to see if one can do something useful with with the ifIndex sent in PtoP Router LSA for unnumbered links. It really doesn't seem to hold some useful info so why send it in the first place? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Jan 18 15:05:30 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 AC5273A6B69; Sun, 18 Jan 2009 15:05:30 -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 0EF303A6B69 for ; Sun, 18 Jan 2009 15:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 LXdBgZgp-icC for ; Sun, 18 Jan 2009 15:05:29 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id F276F3A6B67 for ; Sun, 18 Jan 2009 15:05:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSXO1p2ZYMYkbmatt8iIs81goZNeKgPeO@postini.com; Sun, 18 Jan 2009 15:05:14 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.336.0; Sun, 18 Jan 2009 15:02:58 -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); Sun, 18 Jan 2009 15:02:58 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Jan 2009 15:02:58 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Jan 2009 15:02:57 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0IN2vM79879; Sun, 18 Jan 2009 15:02:57 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <1E6C27F6-C331-452D-A061-E7E3EBB9AFCC@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 18 Jan 2009 16:02:56 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 18 Jan 2009 23:02:57.0838 (UTC) FILETIME=[E75244E0:01C979C0] Cc: ospf@ietf.org Subject: Re: [OSPF] PtoP neighbour numbered or unnumbered? 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 On Jan 18, 2009, at 3:17 PM, Joakim Tjernlund wrote: > I am trying to figure out a way to learn if the other end of a PtoP > link > is unnumberd or numbered. > So far no luck. In this case I cannot look at the remote IP address > of the > PtoP link as it > set in both cases. Ideas anyone? There's no way to do this, but it's arguably outside the scope of the protocol. Both ends ought to be configured the same way, or things may get weird in a hurry. OSPF is not a configuration checker, except by accident. > > > I am also trying to see if one can do something useful with with the > ifIndex sent in PtoP Router LSA > for unnumbered links. It really doesn't seem to hold some useful > info so > why send it in the first place? It's handy for finding your own interfaces during the SPF calculation (so you can figure out your next hop interface). Otherwise you need some ancillary data to do so. --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From newaccounts@33.asp040.com Tue Jan 20 04:15:34 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0633A6B7F for ; Tue, 20 Jan 2009 04:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.692 X-Spam-Level: X-Spam-Status: No, score=-14.692 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 PHadzMyJsIeV for ; Tue, 20 Jan 2009 04:15:33 -0800 (PST) Received: from amcc.com.cn (unknown [189.60.72.175]) by core3.amsl.com (Postfix) with SMTP id B17C73A6950 for ; Tue, 20 Jan 2009 04:15:15 -0800 (PST) To: Subject: RE: Administrator From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090120121517.B17C73A6950@core3.amsl.com> Date: Tue, 20 Jan 2009 04:15:15 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Not see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.compareyes.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://methoddegree.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B252. 019 Clements Road. London. SE18 1DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From kqb0d33y2ccis1z6e_ix8s@aft.schuitema.nl Tue Jan 20 07:07:42 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14B03A6B10 for ; Tue, 20 Jan 2009 07:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.576 X-Spam-Level: X-Spam-Status: No, score=-9.576 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_CHELLO_NL=3.595, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 afh-gDooZfjC for ; Tue, 20 Jan 2009 07:07:42 -0800 (PST) Received: from a30159.upc-a.chello.nl (a30159.upc-a.chello.nl [62.163.30.159]) by core3.amsl.com (Postfix) with SMTP id 3A0F93A6BF7 for ; Tue, 20 Jan 2009 07:07:40 -0800 (PST) To: Subject: Administrator, BRANDKEYWORD From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090120150741.3A0F93A6BF7@core3.amsl.com> Date: Tue, 20 Jan 2009 07:07:40 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Not see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.foundpitch.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://methoddegree.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 3, B971. 558 Clements Road. London. SE46 1DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ospf-bounces@ietf.org Tue Jan 20 07:50:09 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 8D8023A6C12; Tue, 20 Jan 2009 07:50:09 -0800 (PST) X-Original-To: ospf@ietf.org Delivered-To: ospf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 070D73A6C0C; Tue, 20 Jan 2009 07:50:08 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090120155009.070D73A6C0C@core3.amsl.com> Date: Tue, 20 Jan 2009 07:50:09 -0800 (PST) Cc: ospf mailing list , ospf chair , Internet Architecture Board , RFC Editor Subject: [OSPF] Document Action: 'OSPF MPR Extension for Ad Hoc Networks' 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org The IESG has approved the following document: - 'OSPF MPR Extension for Ad Hoc Networks ' as an Experimental RFC This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are David Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mpr-04.txt Technical Summary This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and denoted the "OSPFv3 MANET interface type". Working Group Summary The OSPF WG was unable to reach concensus on a single MANET OSPF approach and agreed to go forward with the three competing approaches as experimental RFCs. Document Quality Passes idnits Personnel Dave Ward _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 20 10:28:18 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 341103A69F9; Tue, 20 Jan 2009 10:28:18 -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 EDC183A6895 for ; Tue, 20 Jan 2009 10:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=0.999, 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 KmRJf5-4Zt6k for ; Tue, 20 Jan 2009 10:28:16 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id C83CA3A680B for ; Tue, 20 Jan 2009 10:28:14 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jan 2009 19:27:54 +0100 To: ospf@ietf.org MIME-Version: 1.0 X-KeepSent: 866BD874:1F545789-C1257544:0055B57E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 20 Jan 2009 19:27:52 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-20 19:27:45, Serialize complete at 2009-01-20 19:27:45 X-OriginalArrivalTime: 20 Jan 2009 18:27:54.0361 (UTC) FILETIME=[CF4F0690:01C97B2C] Subject: [OSPF] nexthop 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 OSPF RCF 2328, chap 16.1.1, last para reads: In the second case, the parent vertex is a network that directly connects the calculating router to the destination router. The list of next hops is then determined by examining the destination's router-LSA. For each link in the router-LSA that points back to the parent network, the link's Link Data field provides the IP address of a next hop router. The outgoing interface to use can then be derived from the next hop IP address (or it can be inherited from the parent network). I am having trouble telling which parts of the router LSA one should consider. There are four types: Link type Description Link ID __________________________________________________ 1 Point-to-point Neighbor Router ID link 2 Link to transit Interface address of network Designated Router 3 Link to stub IP network number network 4 Virtual link Neighbor Router ID Type 3 and 4 isn't used here but what about type 1, should one look in those for a matching IP address? To me only type 2 makes sense though. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 20 10:52: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 82A543A69FB; Tue, 20 Jan 2009 10:52: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 975253A69FB for ; Tue, 20 Jan 2009 10:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 iOXyJRRC3+Nk for ; Tue, 20 Jan 2009 10:52:08 -0800 (PST) Received: from securemail.onebox.com (outgoing3.onebox.com [69.25.242.13]) by core3.amsl.com (Postfix) with ESMTP id 9601A3A6942 for ; Tue, 20 Jan 2009 10:52:08 -0800 (PST) Received: from homexpc (unverified [24.7.51.248]) by securemail.onebox.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Tue, 20 Jan 2009 13:51:50 -0500 From: "Sean Andersen" To: "'Joakim Tjernlund'" , References: Date: Tue, 20 Jan 2009 10:51:49 -0800 Message-ID: <14842AE7A5944227B77EE637E169CA29@homexpc> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acl7LNnSQB160gYwSYOYI6DKMmtj6gAAssQg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [OSPF] nexthop 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 Jocke, I am not sure what you are asking here. The next hop is the described in the destination's router LSA depending on the network type. And the outgoing interface to use is the one that is on the network of the next hop's IP address, or the inherited network. Sean -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Joakim Tjernlund Sent: Tuesday, January 20, 2009 10:28 AM To: ospf@ietf.org Subject: [OSPF] nexthop question. OSPF RCF 2328, chap 16.1.1, last para reads: In the second case, the parent vertex is a network that directly connects the calculating router to the destination router. The list of next hops is then determined by examining the destination's router-LSA. For each link in the router-LSA that points back to the parent network, the link's Link Data field provides the IP address of a next hop router. The outgoing interface to use can then be derived from the next hop IP address (or it can be inherited from the parent network). I am having trouble telling which parts of the router LSA one should consider. There are four types: Link type Description Link ID __________________________________________________ 1 Point-to-point Neighbor Router ID link 2 Link to transit Interface address of network Designated Router 3 Link to stub IP network number network 4 Virtual link Neighbor Router ID Type 3 and 4 isn't used here but what about type 1, should one look in those for a matching IP address? To me only type 2 makes sense though. 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 Tue Jan 20 11:01: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 473F83A6875; Tue, 20 Jan 2009 11:01:44 -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 BF0A63A67E3 for ; Tue, 20 Jan 2009 11:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 EHucHXMG9+5o for ; Tue, 20 Jan 2009 11:01:42 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 8319F3A6B18 for ; Tue, 20 Jan 2009 11:01:40 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSXYfhNYw56P/i9hmxW7EzNI8uD79Je2E@postini.com; Tue, 20 Jan 2009 11:01:27 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.336.0; Tue, 20 Jan 2009 10:59:37 -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); Tue, 20 Jan 2009 10:59:37 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 10:59:37 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 10:59:36 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0KIxaM55123; Tue, 20 Jan 2009 10:59:36 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Joakim Tjernlund In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 11:59:35 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 20 Jan 2009 18:59:36.0796 (UTC) FILETIME=[3D3F91C0:01C97B31] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 I think you're confusing Link ID and Link Data. But for what it's worth, for most implementations, point-to-point links have no next-hop address, so the issue is moot. This avoids the issue of having to know or care whether the far end is numbered or unnumbered. On Jan 20, 2009, at 11:27 AM, Joakim Tjernlund wrote: > OSPF RCF 2328, chap 16.1.1, last para reads: > In the second case, the parent vertex is a network that > directly connects the calculating router to the destination > router. The list of next hops is then determined by > examining the destination's router-LSA. For each link in > the router-LSA that points back to the parent network, the > link's Link Data field provides the IP address of a next > hop > router. The outgoing interface to use can then be derived > from the next hop IP address (or it can be inherited from > the parent network). > > I am having trouble telling which parts of the router LSA one should > consider. There are four types: > Link type Description Link ID > __________________________________________________ > 1 Point-to-point Neighbor Router ID > link > 2 Link to transit Interface address of > network Designated Router > 3 Link to stub IP network number > network > 4 Virtual link Neighbor Router ID > > > Type 3 and 4 isn't used here but what about type 1, should one look in > those > for a matching IP address? > To me only type 2 makes sense though. > > 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 Tue Jan 20 11:05:05 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 0ADE23A6B3E; Tue, 20 Jan 2009 11:05:05 -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 6226F3A6B91 for ; Tue, 20 Jan 2009 11:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=0.951, 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 NeI3EoCPNd2H for ; Tue, 20 Jan 2009 11:05:02 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 0F7213A6B3E for ; Tue, 20 Jan 2009 11:05:01 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jan 2009 20:04:45 +0100 In-Reply-To: <14842AE7A5944227B77EE637E169CA29@homexpc> References: <14842AE7A5944227B77EE637E169CA29@homexpc> To: "Sean Andersen" MIME-Version: 1.0 X-KeepSent: 36368CBC:4F867271-C1257544:0067E4EA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 20 Jan 2009 20:04:44 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-20 20:04:36, Serialize complete at 2009-01-20 20:04:36 X-OriginalArrivalTime: 20 Jan 2009 19:04:45.0288 (UTC) FILETIME=[F51FB680:01C97B31] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 "Sean Andersen" wrote on 20/01/2009 19:51:49: > > Jocke, > > I am not sure what you are asking here. The next hop is the described in the > destination's router LSA depending on the network type. And the outgoing > interface to use is the one that is on the network of the next hop's IP > address, or the inherited network. You scan the router LSA to find potential matches. You should be able to disregard some entries in the router LSA based on link type only. To me it feels like you should only look at the link type 2 entries for an nexthop IP addresses. > > Sean > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Joakim Tjernlund > Sent: Tuesday, January 20, 2009 10:28 AM > To: ospf@ietf.org > Subject: [OSPF] nexthop question. > > OSPF RCF 2328, chap 16.1.1, last para reads: > In the second case, the parent vertex is a network that > directly connects the calculating router to the destination > router. The list of next hops is then determined by > examining the destination's router-LSA. For each link in > the router-LSA that points back to the parent network, the > link's Link Data field provides the IP address of a next hop > router. The outgoing interface to use can then be derived > from the next hop IP address (or it can be inherited from > the parent network). > > I am having trouble telling which parts of the router LSA one should > consider. There are four types: > Link type Description Link ID > __________________________________________________ > 1 Point-to-point Neighbor Router ID > link > 2 Link to transit Interface address of > network Designated Router > 3 Link to stub IP network number > network > 4 Virtual link Neighbor Router ID > > > Type 3 and 4 isn't used here but what about type 1, should one look in > those > for a matching IP address? > To me only type 2 makes sense though. > > 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 Tue Jan 20 11:12:29 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 716133A6BE3; Tue, 20 Jan 2009 11:12:29 -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 590963A6BE3 for ; Tue, 20 Jan 2009 11:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=0.908, 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 FSC7TRmfLMS0 for ; Tue, 20 Jan 2009 11:12:27 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 2B3393A6B91 for ; Tue, 20 Jan 2009 11:12:26 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jan 2009 20:12:10 +0100 In-Reply-To: References: To: Dave Katz MIME-Version: 1.0 X-KeepSent: C0E3D8C7:17B2B96D-C1257544:0068E973; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 20 Jan 2009 20:12:09 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-20 20:12:01, Serialize complete at 2009-01-20 20:12:01 X-OriginalArrivalTime: 20 Jan 2009 19:12:10.0451 (UTC) FILETIME=[FE763230:01C97B32] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 Dave Katz wrote on 20/01/2009 19:59:35: > > I think you're confusing Link ID and Link Data. Possibly, but I am looking at an existing impl. here and I am trying to make sense of it :) > > But for what it's worth, for most implementations, point-to-point > links have no next-hop address, so the issue is moot. This avoids the > issue of having to know or care whether the far end is numbered or > unnumbered. But PtoP links can have an IP address and if they do, should link type 1 be considered? > > On Jan 20, 2009, at 11:27 AM, Joakim Tjernlund wrote: > > > OSPF RCF 2328, chap 16.1.1, last para reads: > > In the second case, the parent vertex is a network that > > directly connects the calculating router to the destination > > router. The list of next hops is then determined by > > examining the destination's router-LSA. For each link in > > the router-LSA that points back to the parent network, the > > link's Link Data field provides the IP address of a next > > hop > > router. The outgoing interface to use can then be derived > > from the next hop IP address (or it can be inherited from > > the parent network). > > > > I am having trouble telling which parts of the router LSA one should > > consider. There are four types: > > Link type Description Link ID > > __________________________________________________ > > 1 Point-to-point Neighbor Router ID > > link > > 2 Link to transit Interface address of > > network Designated Router > > 3 Link to stub IP network number > > network > > 4 Virtual link Neighbor Router ID > > > > > > Type 3 and 4 isn't used here but what about type 1, should one look in > > those > > for a matching IP address? > > To me only type 2 makes sense though. > > > > 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 Tue Jan 20 11:42:47 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 3DDBC3A6BC6; Tue, 20 Jan 2009 11:42:47 -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 2781F3A6BC6 for ; Tue, 20 Jan 2009 11:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 WTqvFwUm72bO for ; Tue, 20 Jan 2009 11:42:45 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 6F7673A69CF for ; Tue, 20 Jan 2009 11:42:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSXYpI1u1elkWouO0zAs+/7bYhnv41KzO@postini.com; Tue, 20 Jan 2009 11:42:29 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.336.0; Tue, 20 Jan 2009 11:42:13 -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); Tue, 20 Jan 2009 11:42:12 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 11:42:12 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 11:42:12 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0KJg9M77082; Tue, 20 Jan 2009 11:42:11 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Joakim Tjernlund In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 12:42:09 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 20 Jan 2009 19:42:12.0169 (UTC) FILETIME=[305E8B90:01C97B37] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 On Jan 20, 2009, at 12:12 PM, Joakim Tjernlund wrote: >> But for what it's worth, for most implementations, point-to-point >> links have no next-hop address, so the issue is moot. This avoids >> the >> issue of having to know or care whether the far end is numbered or >> unnumbered. > > But PtoP links can have an IP address and if they do, should link type > 1 be considered? If you're only installing an interface nexthop, why would you care? If you want to come up with a next hop address, you have the side issue you touched on earlier, which is trying to discern whether the far end is numbered (in which case the link data would be the next hop address) or unnumbered (in which case the link data would be an interface index that means nothing to you.) Other than attempting to apply heuristics to the data to find out if it is an interface index or not (I don't remember whether SNMP defined indices as something less than 32 bits; if not, there is no heuristic that can work) the only choice is to look at your own numbered/unnumbered configuration and hope the other guy is set up the same way. It all gets tricky when there are multiple links between pairs of systems as well, as you need to correlate the LSAs to interfaces... --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From nerirob@advantagehk.com Tue Jan 20 19:33:34 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09CF3A69EA for ; Tue, 20 Jan 2009 19:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.737 X-Spam-Level: X-Spam-Status: No, score=-31.737 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 vwLW6xFXixq7 for ; Tue, 20 Jan 2009 19:33:28 -0800 (PST) Received: from 60-242-206-175.static.tpgi.com.au (60-242-206-175.static.tpgi.com.au [60.242.206.175]) by core3.amsl.com (Postfix) with SMTP id E17193A69CC for ; Tue, 20 Jan 2009 19:33:26 -0800 (PST) To: Subject: Your Payment Has Been Initiated From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121033326.E17193A69CC@core3.amsl.com> Date: Tue, 20 Jan 2009 19:33:26 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.segmentanimal.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://segmentanimal.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 0, B441. 600 Clements Road. London. SE61 8DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ospf-bounces@ietf.org Tue Jan 20 19:36:55 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 616103A69B8; Tue, 20 Jan 2009 19:36:55 -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 980753A69B8 for ; Tue, 20 Jan 2009 19:36:53 -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 EItoS4qKilN1 for ; Tue, 20 Jan 2009 19:36:52 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id BF1ED3A69B3 for ; Tue, 20 Jan 2009 19:36:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSXaYMb27O5MN6HmgpZvDmOqBcQT6cwWW@postini.com; Tue, 20 Jan 2009 19:36:37 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.336.0; Tue, 20 Jan 2009 19:34:07 -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); Tue, 20 Jan 2009 19:34:07 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 19:34:07 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 19:34:06 -0800 Received: from [127.0.0.1] (sa-nc-spg-17.static.jnpr.net [172.23.1.17]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0L3Y6M07140 for ; Tue, 20 Jan 2009 19:34:06 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <497697AD.7000002@juniper.net> Date: Tue, 20 Jan 2009 19:34:05 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ospf@ietf.org X-OriginalArrivalTime: 21 Jan 2009 03:34:06.0751 (UTC) FILETIME=[1D2CE2F0:01C97B79] Subject: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF 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" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org I have a question about RFC 2328 w.r.t. ignoring self-originated type 3 and type 5 LSAs when running SPF. According to item (2) in section 16.2 and item (2) in section 16.4 of the RFC, self-originated type 3 and type 5 LSAs are to be ignored when calculating inter-area and external routes. Can someone explain the rationale behind these rules? On the surface it seems that following these rules, particularly for type 5 LSAs, causes somewhat strange behavior wherein we add an OSPF route pointing to another ASBR originating the route even though we ourselves are advertising the same route. Of course, these external routes typically never get into the FIB due to the presence of the corresponding non-OSPF routes that are being advertised into OSPF. However, I am trying to understand why these routes should even get added into the OSPF routing table with a next-hop pointing to another ASBR. Thanks, Nischal _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 20 20:50:41 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 9E6733A6991; Tue, 20 Jan 2009 20:50:41 -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 EB0D33A6991 for ; Tue, 20 Jan 2009 20:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 VeWxSis+hpMN for ; Tue, 20 Jan 2009 20:50:39 -0800 (PST) Received: from web57102.mail.re3.yahoo.com (web57102.mail.re3.yahoo.com [216.252.111.115]) by core3.amsl.com (Postfix) with SMTP id CC5893A6824 for ; Tue, 20 Jan 2009 20:50:38 -0800 (PST) Received: (qmail 45506 invoked by uid 60001); 21 Jan 2009 04:50:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=b8Pv4W3thJEQT9j6UT6CrTCAnjeN588x2DpY6JHnAL6s+Ixq/aNuwal+3mFvbeNwlLbso2/LNEnw7HeZtDDNr3t2jOfWeVSePyPnPAf/MGRaxA1Agla5Ex7Hek6o3wv1Zps8Dq9r5Gx2zVJlO5VsRApEv1c6bxddgSQ77gzRkqs=; X-YMail-OSG: 1oa6.UsVM1kdoG5DxfvNYr9qnpI.wyaOaM.7lIcSIsgBiK1oXpYB9p.PH0njXdWig_ulCUrnDeNg55kHf6Jklys6gV._VRcTZnuaj9R8IdcGd_0BnNfU8EM7yYNGyaHEc76G2kQ1e7qai_3IuwujKR2z7TkW4jZPVQIDTPfT1aFbkH7Lbqx1nM4ZpYadm_i0drQsB0I_mp9g76DxIZhKPcvZpPM- Received: from [125.17.98.11] by web57102.mail.re3.yahoo.com via HTTP; Tue, 20 Jan 2009 20:50:22 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Tue, 20 Jan 2009 20:50:22 -0800 (PST) From: Sengottuvelan Srirangan To: Nischal Sheth In-Reply-To: <497697AD.7000002@juniper.net> MIME-Version: 1.0 Message-ID: <56480.44978.qm@web57102.mail.re3.yahoo.com> Cc: ospf@ietf.org Subject: Re: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sengottuvelan_s@yahoo.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1780440999==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1780440999== Content-Type: multipart/alternative; boundary="0-115488776-1232513422=:44978" --0-115488776-1232513422=:44978 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Nischal, =A0 In 16.2 and 16.4, You need to check the items for=A0calculating Reachabilit= y to Boundary Router=A0(BR)/AS boundary router (ASBR) ie. Looking up the ro= uting table entry for BR or ASBR in RFC 2328, section 16.2 and 16.4 before = adding to the OSPF routing Table. =A0 Finally, Please check for path selection rules=A0for inter-area routes and = external-routes in the same sections pointed out earlier. =A0 Regards Sengottuvelan =A0 --- On Wed, 1/21/09, Nischal Sheth wrote: From: Nischal Sheth Subject: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF To: ospf@ietf.org Date: Wednesday, January 21, 2009, 8:34 AM I have a question about RFC 2328 w.r.t. ignoring self-originated type 3 and type 5 LSAs when running SPF. According to item (2) in section 16.2 and item (2) in section 16.4 of the RFC, self-originated type 3 and type 5 LSAs are to be ignored when calculating inter-area and external routes. Can someone explain the rationale behind these rules? On the surface it seems that following these rules, particularly for type 5 LSAs, causes somewhat strange behavior wherein we add an OSPF route pointing to another ASBR originating the route even though we ourselves are advertising the same route. Of course, these external routes typically never get into the FIB due to the presence of the corresponding non-OSPF routes that are being advertised into OSPF. However, I am trying to understand why these routes should even get added into the OSPF routing table with a next-hop pointing to another ASBR. Thanks, Nischal _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf =0A=0A=0A --0-115488776-1232513422=:44978 Content-Type: text/html; charset=us-ascii
Hi Nischal,
 
In 16.2 and 16.4, You need to check the items for calculating Reachability to Boundary Router (BR)/AS boundary router (ASBR) ie. Looking up the routing table entry for BR or ASBR in RFC 2328, section 16.2 and 16.4 before adding to the OSPF routing Table.
 
Finally, Please check for path selection rules for inter-area routes and external-routes in the same sections pointed out earlier.
 
Regards
Sengottuvelan


 


--- On Wed, 1/21/09, Nischal Sheth <nsheth@juniper.net> wrote:
From: Nischal Sheth <nsheth@juniper.net>
Subject: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF
To: ospf@ietf.org
Date: Wednesday, January 21, 2009, 8:34 AM

I have a question about RFC 2328 w.r.t. ignoring self-originated type 3
and type 5 LSAs when running SPF.  According to item (2) in section 16.2
and item (2) in section 16.4 of the RFC, self-originated type 3 and type
5 LSAs are to be ignored when calculating inter-area and external routes.

Can someone explain the rationale behind these rules?  On the surface it
seems that following these rules, particularly for type 5 LSAs, causes
somewhat strange behavior wherein we add an OSPF route pointing to another
ASBR originating the route even though we ourselves are advertising the
same route.

Of course, these external routes typically never get into the FIB due to
the presence of the corresponding non-OSPF routes that are being advertised
into OSPF.  However, I am trying to understand why these routes should even
get added into the OSPF routing table with a next-hop pointing to another
ASBR.

Thanks,
Nischal


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

--0-115488776-1232513422=:44978-- --===============1780440999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============1780440999==-- From ospf-bounces@ietf.org Wed Jan 21 01:42:41 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 9A2FD3A68CC; Wed, 21 Jan 2009 01:42:41 -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 0BFE73A6A8B for ; Wed, 21 Jan 2009 01:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=0.869, 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 GbbYqVYfXqkd for ; Wed, 21 Jan 2009 01:42:39 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id CE5D23A68CC for ; Wed, 21 Jan 2009 01:42:37 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jan 2009 10:42:20 +0100 In-Reply-To: References: To: Dave Katz MIME-Version: 1.0 X-KeepSent: 97644276:62BBB57A-C1257545:002DFB40; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Wed, 21 Jan 2009 10:42:18 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-21 10:42:10, Serialize complete at 2009-01-21 10:42:10 X-OriginalArrivalTime: 21 Jan 2009 09:42:20.0241 (UTC) FILETIME=[8DEBEC10:01C97BAC] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 Dave Katz wrote on 20/01/2009 20:42:09: > > On Jan 20, 2009, at 12:12 PM, Joakim Tjernlund wrote: > > >> But for what it's worth, for most implementations, point-to-point > >> links have no next-hop address, so the issue is moot. This avoids > >> the > >> issue of having to know or care whether the far end is numbered or > >> unnumbered. > > > > But PtoP links can have an IP address and if they do, should link type > > 1 be considered? > > If you're only installing an interface nexthop, why would you care? > > If you want to come up with a next hop address, you have the side > issue you touched on earlier, which is trying to discern whether the > far end is numbered (in which case the link data would be the next hop > address) or unnumbered (in which case the link data would be an > interface index that means nothing to you.) Other than attempting to > apply heuristics to the data to find out if it is an interface index > or not (I don't remember whether SNMP defined indices as something > less than 32 bits; if not, there is no heuristic that can work) the > only choice is to look at your own numbered/unnumbered configuration > and hope the other guy is set up the same way. > > It all gets tricky when there are multiple links between pairs of > systems as well, as you need to correlate the LSAs to interfaces... OK, I understand. No need to supply a next hop address for PtoP links. I still got a problem though :( The text "for each link in the router-LSA that points back to the parent network" is where I still got a problem. How do I find the correct ones? Since router ID and Interface address may have the same value, I cant just match Network vertex ID against every entry in the Router LSA. Since the parent vertex is a network, I figured that the only thing I can match is the Network vertex ID against is link ID in link type 2 (Link to transit network) and use the link data is nexthop address. The text says that each link should "point back to the parent network" and that implies to me that you should only consider links that is attached to a network and to me PtoP links never points to a network so one should exclude PtoP links as possible nexthops. I am probably very confused so if you could give me a clue or two, I would be very grateful. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 21 05:58:01 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 0CC563A6A6E; Wed, 21 Jan 2009 05:58:01 -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 75E6E3A6A6E for ; Wed, 21 Jan 2009 05:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-3.300, BAYES_50=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 KGUmC3Ij7N+j for ; Wed, 21 Jan 2009 05:57:59 -0800 (PST) Received: from web27203.mail.ukl.yahoo.com (web27203.mail.ukl.yahoo.com [217.146.182.93]) by core3.amsl.com (Postfix) with SMTP id 871483A694F for ; Wed, 21 Jan 2009 05:57:59 -0800 (PST) Received: (qmail 91681 invoked by uid 60001); 21 Jan 2009 13:57:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=QY9GrARf0qCa3/JMNFiG/R71PTmnDOvivvBzyxIxQqtSBVHCN6jYBoWs4rh8Z7ZFo2frXrFZz+7B36CnPKkRYVQcwtfnMmBceunmXF7jNtHCxCZUKgOykQmccYlsFeYd3QWkbtDS7lOT4WpaqPjZjYPrz3L9rCbJ+7ize0toUQk=; X-YMail-OSG: c4UwshcVM1mdHjbFC7i9DCMRNgyLFl7FfCjdEPvS_MOSeWUS0saO.buJHW3QGhcwz8gFjwzWOgcPV3nEdQW2t2pbN.drWP2OBeoP22.yPd4FYz03aHAH_h8XQ2u6gGTby2eetzo7oZEfDdbF6per3NkDjfz87YVFQXE1YsjyBCpf2814ROeWtbk6a2Rtjg-- Received: from [122.167.245.61] by web27203.mail.ukl.yahoo.com via HTTP; Wed, 21 Jan 2009 13:57:42 GMT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: Date: Wed, 21 Jan 2009 13:57:42 +0000 (GMT) From: John Smith To: OSPF List MIME-Version: 1.0 Message-ID: <645047.91603.qm@web27203.mail.ukl.yahoo.com> Subject: [OSPF] p2p and nbma 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi, I want to understand what data link layer technology is referred to when we talk of p2p and nbma networks in OSPF? I believe nbma alludes to ATM and Frame Relay networks. If so, then we will see the # of nbma networks going down as more and more ethernet networks are replacing atm and FR. Can a MPLS tunnel be a p2p network in OSPF? What is a p2p network - a serial interface? Thanks, John _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 21 08:01:53 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 0608828C1A7; Wed, 21 Jan 2009 08:01:53 -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 BA2A628C150 for ; Wed, 21 Jan 2009 08:01:51 -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 GboUdgYyYrkb for ; Wed, 21 Jan 2009 08:01:48 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id 377AE28C1B7 for ; Wed, 21 Jan 2009 08:01:19 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01N4JTOR0SU800GIOS@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Wed, 21 Jan 2009 08:00:51 -0700 (PDT) Date: Wed, 21 Jan 2009 08:00:51 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: JSMITH4112003@YAHOO.CO.UK Message-id: <01N4JTOR0SUA00GIOS@omega7.wr.usgs.gov> X-VMS-To: jsmith4112003@yahoo.co.uk X-VMS-Cc: PMURPHY,ospf@ietf.org MIME-version: 1.0 Cc: OSPF@IETF.ORG Subject: [OSPF] p2p and nbma 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org John, >I want to understand what data link layer technology is referred to >when we talk of p2p and nbma networks in OSPF? I believe nbma alludes >to ATM and Frame Relay networks. If so, then we will see the # of nbma >networks going down as more and more ethernet networks are replacing >atm and FR. A p2p network type configuration is commonly deployed over ATM, FR, and Serial. I suppose p2p between two routers connected by an ethernet crossover cable would be possible. But what would be the point of complicating a configuration by choosing p2p over the default broadcast network type? The broadcast network type is normally thought to be Ethernet technology; but some ATM and FR clouds will also support OSPF multicast packets. I personally have never seen this used. Perhaps others can share some unusual p2p and broadcast network type deployments. The key requirement for deploying p2p and broadcast network types is support for OSPF multicast packets. p2mp and nbma can be configured over any technology. I have seen both deployed for different reasons over carrier ethernet service. Their distinct advantage is that all OSPF packets are unicast (versus multicast) between neighbors. Note that a p2mp cloud with only two routers is just a unicast version of p2p. >Can a MPLS tunnel be a p2p network in OSPF? What is a p2p network - >serial interface? In OSPF (RFC 2328 Section 9.5) a p2p network is simply a connection between two routers who discover each other using Hello packets sent to the multicast address AllSPFRouters (224.0.0.5). Many implementation interface types support this. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 21 11:08:09 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 31AFC3A67AF; Wed, 21 Jan 2009 11:08:09 -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 078C73A67D9 for ; Wed, 21 Jan 2009 11:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 rDM09pHij2D7 for ; Wed, 21 Jan 2009 11:08:07 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 466F73A67A8 for ; Wed, 21 Jan 2009 11:08:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 47C12B8F82E; Wed, 21 Jan 2009 11:07:51 -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 17404-09; Wed, 21 Jan 2009 11:07:51 -0800 (PST) Received: from [IPv6???1] (lxlogin-2-300.redback.com [155.53.12.217]) by prattle.redback.com (Postfix) with ESMTP id 7E580B8F82B; Wed, 21 Jan 2009 11:07:50 -0800 (PST) In-Reply-To: <497697AD.7000002@juniper.net> References: <497697AD.7000002@juniper.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <0B677CD8-1FC9-429D-A1A4-4329F2BAE5D8@redback.com> From: Acee Lindem Date: Wed, 21 Jan 2009 14:07:48 -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] ignoring self-originated type 3/5 LSAs when running SPF 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 Nischal, Your concern doesn't apply to type 3 summaries since that fact that you are advertising a summary into the backbone implies that you have an intra-area route in a non-backbone area - the intra-area route will be preferred over a summary from any other router. For ASE and NSSA prefixes, local RIB policy can be used to determine whether you want to prefer your redistributed route or an AS External or NSSA route learned via OSPF. If the OSPF AS external calculation enforced a strict "split-horizon" rule, you would not be able to do the latter. Thanks, Acee On Jan 20, 2009, at 10:34 PM, Nischal Sheth wrote: > > I have a question about RFC 2328 w.r.t. ignoring self-originated > type 3 > and type 5 LSAs when running SPF. According to item (2) in section > 16.2 > and item (2) in section 16.4 of the RFC, self-originated type 3 and > type > 5 LSAs are to be ignored when calculating inter-area and external > routes. > > Can someone explain the rationale behind these rules? On the > surface it > seems that following these rules, particularly for type 5 LSAs, causes > somewhat strange behavior wherein we add an OSPF route pointing to > another > ASBR originating the route even though we ourselves are advertising > the > same route. > > Of course, these external routes typically never get into the FIB > due to > the presence of the corresponding non-OSPF routes that are being > advertised > into OSPF. However, I am trying to understand why these routes > should even > get added into the OSPF routing table with a next-hop pointing to > another > ASBR. > > Thanks, > Nischal > > > _______________________________________________ > 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 Wed Jan 21 11:27: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 DAC4828C0F3; Wed, 21 Jan 2009 11:27: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 05FD328C123 for ; Wed, 21 Jan 2009 11:27:16 -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 BicVUN9qH8MY for ; Wed, 21 Jan 2009 11:27:15 -0800 (PST) Received: from mx.force10networks.com (corp.force10networks.com [64.186.164.204]) by core3.amsl.com (Postfix) with ESMTP id 29C5F28C0F3 for ; Wed, 21 Jan 2009 11:27:15 -0800 (PST) Received: from EXCH-CLUSTER-08.force10networks.com ([10.11.10.111]) by exch7-sjc-fe.force10networks.com ([10.11.0.87]) with mapi; Wed, 21 Jan 2009 11:26:59 -0800 From: Nitin Kakkar To: Acee Lindem , Nischal Sheth Date: Wed, 21 Jan 2009 11:26:57 -0800 Thread-Topic: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF Thread-Index: Acl7+5AfrolUBYz0S8il8DQDJWN/MQAAPoTw Message-ID: <879BDCD311B18047914F9B9DA37E1606148E02B7@EXCH-CLUSTER-08.force10networks.com> References: <497697AD.7000002@juniper.net> <0B677CD8-1FC9-429D-A1A4-4329F2BAE5D8@redback.com> In-Reply-To: <0B677CD8-1FC9-429D-A1A4-4329F2BAE5D8@redback.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF 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 Nischal, Another dimension for your thought process, Think how does ospf originate T5 & T3 LSA's? Some other protocol (T5's ) or ospf from another area (T3's case), inside the box already have route to these destinations. Ospf is merely *relaying* this reach-ability information to its domain. Now lets say ospf use self originated lsa's and calculate paths, with incorrect path selection rule in rtm or fib, one can end up with routing loops. So what is the safest way to avoid such problems? Again Remember destinations given by self originated T3 & T5 prefixes are not new, they are already available in control & forwarding domains, so we are not missing out on any route. Hope this helps Nitin -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Wednesday, January 21, 2009 11:08 AM To: Nischal Sheth Cc: ospf@ietf.org Subject: Re: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF Hi Nischal, Your concern doesn't apply to type 3 summaries since that fact that you are advertising a summary into the backbone implies that you have an intra-area route in a non-backbone area - the intra-area route will be preferred over a summary from any other router. For ASE and NSSA prefixes, local RIB policy can be used to determine whether you want to prefer your redistributed route or an AS External or NSSA route learned via OSPF. If the OSPF AS external calculation enforced a strict "split-horizon" rule, you would not be able to do the latter. Thanks, Acee On Jan 20, 2009, at 10:34 PM, Nischal Sheth wrote: > > I have a question about RFC 2328 w.r.t. ignoring self-originated > type 3 > and type 5 LSAs when running SPF. According to item (2) in section > 16.2 > and item (2) in section 16.4 of the RFC, self-originated type 3 and > type > 5 LSAs are to be ignored when calculating inter-area and external > routes. > > Can someone explain the rationale behind these rules? On the > surface it > seems that following these rules, particularly for type 5 LSAs, causes > somewhat strange behavior wherein we add an OSPF route pointing to > another > ASBR originating the route even though we ourselves are advertising > the > same route. > > Of course, these external routes typically never get into the FIB > due to > the presence of the corresponding non-OSPF routes that are being > advertised > into OSPF. However, I am trying to understand why these routes > should even > get added into the OSPF routing table with a next-hop pointing to > another > ASBR. > > Thanks, > Nischal > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 21 11:39:20 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 5F36128C123; Wed, 21 Jan 2009 11:39:20 -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 0D4BE3A68CD for ; Wed, 21 Jan 2009 11:39:19 -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 6VoSXfUeQuKS for ; Wed, 21 Jan 2009 11:39:18 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 45BCC3A67F8 for ; Wed, 21 Jan 2009 11:39:18 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSXd50Z8n8SRAOQGcOmuDSvuyREzENsg5@postini.com; Wed, 21 Jan 2009 11:39:02 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.336.0; Wed, 21 Jan 2009 11:37:48 -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); Wed, 21 Jan 2009 11:37:47 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 11:37:47 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 11:37:47 -0800 Received: from [127.0.0.1] (sa-nc-spg-47.static.jnpr.net [172.23.1.47]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0LJblM80832; Wed, 21 Jan 2009 11:37:47 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <4977798A.1000104@juniper.net> Date: Wed, 21 Jan 2009 11:37:46 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Acee Lindem References: <497697AD.7000002@juniper.net> <0B677CD8-1FC9-429D-A1A4-4329F2BAE5D8@redback.com> In-Reply-To: <0B677CD8-1FC9-429D-A1A4-4329F2BAE5D8@redback.com> X-OriginalArrivalTime: 21 Jan 2009 19:37:47.0032 (UTC) FILETIME=[BCBF9980:01C97BFF] Cc: ospf@ietf.org Subject: Re: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF 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" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Acee Lindem wrote: > Hi Nischal, > Your concern doesn't apply to type 3 summaries since that fact that you > are advertising a summary into the backbone implies that you have an > intra-area route in a non-backbone area - the intra-area route will be > preferred over a summary from any other router. For ASE and NSSA > prefixes, local RIB policy can be used to determine whether you want to > prefer your redistributed route or an AS External or NSSA route learned > via OSPF. If the OSPF AS external calculation enforced a strict > "split-horizon" rule, you would not be able to do the latter. > Hi Acee, Thanks for responding. Your explanation w.r.t. the ASE and NSSA prefixes makes sense. -Nischal _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jan 21 12:11:31 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 067F43A6881; Wed, 21 Jan 2009 12:11:31 -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 977063A6881 for ; Wed, 21 Jan 2009 12:11:29 -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 2XiYnJBxPJuY for ; Wed, 21 Jan 2009 12:11:28 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id B64633A684B for ; Wed, 21 Jan 2009 12:11:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSXeBX0RyB/nOjOhpAVuf8HbqZvciKLmV@postini.com; Wed, 21 Jan 2009 12:11:12 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.336.0; Wed, 21 Jan 2009 12:10:19 -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); Wed, 21 Jan 2009 12:10:19 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 12:10:18 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 12:10:18 -0800 Received: from [127.0.0.1] (sa-nc-spg-47.static.jnpr.net [172.23.1.47]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0LKAIM00104; Wed, 21 Jan 2009 12:10:18 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <4977812A.6040203@juniper.net> Date: Wed, 21 Jan 2009 12:10:18 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Nitin Kakkar References: <497697AD.7000002@juniper.net> <0B677CD8-1FC9-429D-A1A4-4329F2BAE5D8@redback.com> <879BDCD311B18047914F9B9DA37E1606148E02B7@EXCH-CLUSTER-08.force10networks.com> In-Reply-To: <879BDCD311B18047914F9B9DA37E1606148E02B7@EXCH-CLUSTER-08.force10networks.com> X-OriginalArrivalTime: 21 Jan 2009 20:10:18.0648 (UTC) FILETIME=[48009180:01C97C04] Cc: "ospf@ietf.org" Subject: Re: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF 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" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Nitin Kakkar wrote: > Nischal, > Another dimension for your thought process, > Think how does ospf originate T5 & T3 LSA's? > Some other protocol (T5's ) or ospf from another area (T3's case), inside the box already have route to these destinations. Ospf is merely *relaying* this reach-ability information to its domain. > > Now lets say ospf use self originated lsa's and calculate paths, with incorrect path selection rule in rtm or fib, one can end up with routing loops. > So what is the safest way to avoid such problems? > > Again Remember destinations given by self originated T3 & T5 prefixes are not new, they are already available in control & forwarding domains, so we are not missing out on any route. > Hi Nitin, It appears to me that imposing a strict split-horizon rule in OSPF itself i.e. do not install ASE/NSSA routes pointing to another ASBR if we are originating the same prefix, would ensure that we don't get loops. The rules specified in RFC 2328 provide you more flexibility, as Acee pointed out. However, you can create loops if local RIB policy is not configured correctly e.g. both ASBRs are configured to prefer the OSPF learnt route over the redistributed route. This seems to be a reasonable tradeoff. Thanks, Nischal _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jan 22 07:07:18 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 28F623A6886; Thu, 22 Jan 2009 07:07:18 -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 BB4783A67ED for ; Thu, 22 Jan 2009 07:07: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 TB-AIJcqDsGa for ; Thu, 22 Jan 2009 07:07:12 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 530B93A6886 for ; Thu, 22 Jan 2009 07:07:12 -0800 (PST) Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0MF6pe11172 for ; Thu, 22 Jan 2009 15:06:51 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 15:07:10 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] How to announce an unnumbered PtP link in the LSDB Thread-Index: Acl7MfyFhS1DquxNQ0a7YBNCKWDEIwBb1EeA References: <14842AE7A5944227B77EE637E169CA29@homexpc> From: "Juergen Arlt" To: Subject: [OSPF] How to announce an unnumbered PtP link in the LSDB 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 I have a router that is connected over the WAN to another one. It is talking OSPF over that link. The interface uses unnumbered IP (0.0.0.0) and is therefore using an associated IP - which is in fact the IP of another interface on the same box. This associated IP interface has NO OSPF configured. So this interface should it should not appear in the LSDB. In the LSDB however I can see them because the router assumes the associate address on the point to point link and on that link there is OPSF. Is this correct? How should OSPF announce an unnumbered point to point link? Should this network be announced at all? Which address shall be used to announce? Thanks Juergen Arlt _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From info@bezeqint.net Thu Jan 22 08:29:35 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A9C3A68B6 for ; Thu, 22 Jan 2009 08:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 gljFTu7KW6Vm for ; Thu, 22 Jan 2009 08:29:29 -0800 (PST) Received: from omr1.bezeqint.net (omr1.bezeqint.net [192.115.104.8]) by core3.amsl.com (Postfix) with ESMTP id 582683A69BC for ; Thu, 22 Jan 2009 08:29:28 -0800 (PST) Received: from mas25.bezeqint.net (mas25.bezeqint.net [192.115.104.155]) by omr1.bezeqint.net (Bezeq International SMTP out Mail Server) with ESMTP id 75428161F8C; Thu, 22 Jan 2009 18:23:32 +0200 (IST) Received: (from mas25.bezeqint.net [192.115.104.137]) by mas25.bezeqint.net (MOS 3.8.6-GA) with HTTP/1.1 id FDC46572 (AUTH milmnctr); Thu, 22 Jan 2009 18:21:42 +0200 (IST) From: UPGRAE TEAM Subject: Dear Bezeqint Email User, Reply-To: upgradeteam009@yahoo.com X-Mailer: Mirapoint Webmail Direct 3.8.6-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20090122182142.FDC46572@mas25.bezeqint.net> Date: Thu, 22 Jan 2009 18:21:42 +0200 (IST) To: undisclosed-recipients:; Dear Bezeqint Email User, To complete your account activation with us, you are required to reply to this message and enter your password in the spaces provided for upgrade in our database. Full Name: Email Id: Password: Your account can also be verified using the link below: https://mail.bezeqint.net/ Thank you for using Bezeqint Mail. From ospf-bounces@ietf.org Thu Jan 22 13:42:15 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 BA7093A6892; Thu, 22 Jan 2009 13:42:15 -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 8A3DD3A680A for ; Thu, 22 Jan 2009 13:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 NkayjU0l7vo8 for ; Thu, 22 Jan 2009 13:42:13 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by core3.amsl.com (Postfix) with ESMTP id 153C33A6892 for ; Thu, 22 Jan 2009 13:42:12 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so3524556mue.9 for ; Thu, 22 Jan 2009 13:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OjaPZzD8v3igX85JawXC8gJ/sPk1yleL21joEhjkzhU=; b=XQMVKYPCA8n8dib78mm2RDCTUfAGj+Crt8vrRhV08FTSRwhIWXGD0vNFSNYUJ/QsjD XCtuM26U2KTS1KyLozN4bnLMS2QOoBRKTVcyXLEDKocT8WSSB8er0L8COWnuoF8Q80SL sbAB7/5fCY8XQ1/TarpnG83grn0STsiHrOqD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tjGKZq5hLnp3MSUrR/+40KfNRq8j9tr+CzIlX4uuxRxKqVzMx0UhwukDG3m3NXo1PU RGAk5IRmCatG+4b2XL+2YNrNtOCfpiU+6tqsHs6jjPp0Ar6ZccUD7n1tf8ZwETcVM8dZ xDFUBcQl2dyJTkVQGCsW9JnA4XXAPhTed7jBo= MIME-Version: 1.0 Received: by 10.181.49.3 with SMTP id b3mr1152306bkk.21.1232660515041; Thu, 22 Jan 2009 13:41:55 -0800 (PST) In-Reply-To: <01N4JTOR0SUA00GIOS@omega7.wr.usgs.gov> References: <01N4JTOR0SUA00GIOS@omega7.wr.usgs.gov> Date: Thu, 22 Jan 2009 16:41:54 -0500 Message-ID: <787be2780901221341h3d7e715q556ae36a4281ea02@mail.gmail.com> From: Greg Mirsky To: "Pat Murphy - (650)329-4044" Cc: JSMITH4112003@yahoo.co.uk, OSPF@ietf.org Subject: Re: [OSPF] p2p and nbma 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: , Content-Type: multipart/mixed; boundary="===============1909895402==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1909895402== Content-Type: multipart/alternative; boundary=00163630fb4920b426046119242a --00163630fb4920b426046119242a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit "... But what would be the point of complicating a configuration by choosing p2p over the default broadcast network type? ..." Pat, I've worked with several OSPF networks where OSPF Interface over p2p Ethernet link was set to p2p. It saves you from unnecessary in this case DR/BDR election. Regards, Greg On Wed, Jan 21, 2009 at 10:00 AM, Pat Murphy - (650)329-4044 < pmurphy@noc.usgs.net> wrote: > John, > > >I want to understand what data link layer technology is referred to > >when we talk of p2p and nbma networks in OSPF? I believe nbma alludes > >to ATM and Frame Relay networks. If so, then we will see the # of nbma > >networks going down as more and more ethernet networks are replacing > >atm and FR. > > A p2p network type configuration is commonly deployed over ATM, FR, and > Serial. I suppose p2p between two routers connected by an ethernet > crossover cable would be possible. But what would be the point of > complicating a configuration by choosing p2p over the default broadcast > network type? The broadcast network type is normally thought to be > Ethernet technology; but some ATM and FR clouds will also support OSPF > multicast packets. I personally have never seen this used. Perhaps > others can share some unusual p2p and broadcast network type > deployments. The key requirement for deploying p2p and broadcast network > types is support for OSPF multicast packets. > > p2mp and nbma can be configured over any technology. I have seen both > deployed for different reasons over carrier ethernet service. Their > distinct advantage is that all OSPF packets are unicast (versus > multicast) between neighbors. Note that a p2mp cloud with only two > routers is just a unicast version of p2p. > > >Can a MPLS tunnel be a p2p network in OSPF? What is a p2p network - > >serial interface? > > In OSPF (RFC 2328 Section 9.5) a p2p network is simply a connection > between two routers who discover each other using Hello packets sent to > the multicast address AllSPFRouters (224.0.0.5). Many implementation > interface types support this. > > Pat > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --00163630fb4920b426046119242a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable "... But what would be the point of complicating a configuration by ch= oosing p2p over the default broadcast
network type? ..."

Pat,
I've worked with several OSPF ne= tworks where OSPF Interface over p2p Ethernet link was set to p2p. It saves= you from unnecessary in this case DR/BDR election.

Regards,
Greg

On Wed, Jan 21, 2009 at 10:00 AM, Pa= t Murphy - (650)329-4044 <pmurphy@noc.usgs.net> wrote:
John,

>I want to understand what data link layer technology is referred to
>when we talk of p2p and nbma networks in OSPF? I believe nbma alludes >to ATM and Frame Relay networks. If so, then we will see the # of nbma<= br> >networks going down as more and more ethernet networks are replacing >atm and FR.

A p2p network type configuration is commonly deployed over ATM, FR, and
Serial. I suppose p2p between two routers connected by an ethernet
crossover cable would be possible. But what would be the point of
complicating a configuration by choosing p2p over the default broadcast
network type? The broadcast network type is normally thought to be
Ethernet technology; but some ATM and FR clouds will also support OSPF
multicast packets. I personally have never seen this used. Perhaps
others can share some unusual p2p and broadcast network type
deployments. The key requirement for deploying p2p and broadcast network types is support for OSPF multicast packets.

p2mp and nbma can be configured over any technology. I have seen both
deployed for different reasons over carrier ethernet service. Their
distinct advantage is that all OSPF packets are unicast (versus
multicast) between neighbors. Note that a p2mp cloud with only two
routers is just a unicast version of p2p.

>Can a MPLS tunnel be a p2p network in OSPF? What is a p2p network -
>serial interface?

In OSPF (RFC 2328 Section 9.5) a p2p network is simply a connection
between two routers who discover each other using Hello packets sent to
the multicast address AllSPFRouters (224.0.0.5). Many implementation
interface types support this.

Pat

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

--00163630fb4920b426046119242a-- --===============1909895402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============1909895402==-- From ospf-bounces@ietf.org Thu Jan 22 17:45:37 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 B70793A69E9; Thu, 22 Jan 2009 17:45:37 -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 3B1883A69E9 for ; Thu, 22 Jan 2009 17:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 PK5K5UDEgO5T for ; Thu, 22 Jan 2009 17:45:31 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 1695C3A67DF for ; Thu, 22 Jan 2009 17:45:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B9F53CAB550; Thu, 22 Jan 2009 17:45:14 -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 10310-05; Thu, 22 Jan 2009 17:45:14 -0800 (PST) Received: from [IPv6???1] (lxlogin-3-300.redback.com [155.53.12.218]) by prattle.redback.com (Postfix) with ESMTP id 5107CCAB54E; Thu, 22 Jan 2009 17:45:12 -0800 (PST) In-Reply-To: References: <14842AE7A5944227B77EE637E169CA29@homexpc> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> From: Acee Lindem Date: Thu, 22 Jan 2009 14:19:41 -0500 To: Juergen Arlt X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB 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 On Jan 22, 2009, at 10:07 AM, Juergen Arlt wrote: > I have a router that is connected over the WAN to another one. It is > talking OSPF over that link. The interface uses unnumbered IP > (0.0.0.0) > and is therefore using an associated IP - which is in fact the IP of > another interface on the same box. > This associated IP interface has NO OSPF configured. So this interface > should it should not appear in the LSDB. > > In the LSDB however I can see them because the router assumes the > associate address on the point to point link and on that link there is > OPSF. > > Is this correct? How should OSPF announce an unnumbered point to point > link? Should this network be announced at all? Which address shall be > used to announce? An unnumbered link without a full adjacency will not result in any links in the router LSA. Thanks, Acee > > Thanks > Juergen Arlt > > > > > > > _______________________________________________ > 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 Fri Jan 23 00:16:26 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 50CDA3A6920; Fri, 23 Jan 2009 00:16:26 -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 6D12F3A6920 for ; Fri, 23 Jan 2009 00:16:25 -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 8aarbrfdjONG for ; Fri, 23 Jan 2009 00:16:20 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id DAC053A67FB for ; Fri, 23 Jan 2009 00:16:19 -0800 (PST) Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0N8Fw716660; Fri, 23 Jan 2009 08:15:58 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Jan 2009 08:16:22 -0000 Message-ID: In-Reply-To: <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] How to announce an unnumbered PtP link in the LSDB Thread-Index: Acl8/D+/MAMKryrsS7+QtBYkKSvmQQANlskg References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> From: "Juergen Arlt" To: "Acee Lindem" Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB 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 Thanks for the answer - is that documented somewhere? And how do you mean without a full adjacency. Aren't the two devices on that point to point link always adjacent? Thanks -----Original Message----- From: Acee Lindem [mailto:acee@redback.com] Sent: Donnerstag, 22. Januar 2009 20:20 To: Arlt, Juergen (GERST:476S) Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB On Jan 22, 2009, at 10:07 AM, Juergen Arlt wrote: > I have a router that is connected over the WAN to another one. It is > talking OSPF over that link. The interface uses unnumbered IP > (0.0.0.0) > and is therefore using an associated IP - which is in fact the IP of > another interface on the same box. > This associated IP interface has NO OSPF configured. So this interface > should it should not appear in the LSDB. > > In the LSDB however I can see them because the router assumes the > associate address on the point to point link and on that link there is > OPSF. > > Is this correct? How should OSPF announce an unnumbered point to point > link? Should this network be announced at all? Which address shall be > used to announce? An unnumbered link without a full adjacency will not result in any links in the router LSA. Thanks, Acee > > Thanks > Juergen Arlt > > > > > > > _______________________________________________ > 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 Fri Jan 23 00:23:32 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 D9A0C3A6920; Fri, 23 Jan 2009 00:23:32 -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 A174D3A6920 for ; Fri, 23 Jan 2009 00:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 W7pVV0-arTZv for ; Fri, 23 Jan 2009 00:23:31 -0800 (PST) Received: from securemail.onebox.com (outgoing3.onebox.com [69.25.242.13]) by core3.amsl.com (Postfix) with ESMTP id C068A3A67FB for ; Fri, 23 Jan 2009 00:23:31 -0800 (PST) Received: from homexpc (unverified [24.7.51.248]) by securemail.onebox.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Fri, 23 Jan 2009 03:23:11 -0500 From: "Sean Andersen" To: "'Juergen Arlt'" , "'Acee Lindem'" References: <14842AE7A5944227B77EE637E169CA29@homexpc><555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> Date: Fri, 23 Jan 2009 00:23:15 -0800 Message-ID: <67C6601D607D4EF6B739FDB833BC984F@homexpc> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: Thread-Index: Acl8/D+/MAMKryrsS7+QtBYkKSvmQQANlskgAAA4cSA= Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB 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 Juergen, Their state is full (as oppose to two way, etc.). That's what Acee is saying. Sean -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Juergen Arlt Sent: Friday, January 23, 2009 12:16 AM To: Acee Lindem Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB Thanks for the answer - is that documented somewhere? And how do you mean without a full adjacency. Aren't the two devices on that point to point link always adjacent? Thanks -----Original Message----- From: Acee Lindem [mailto:acee@redback.com] Sent: Donnerstag, 22. Januar 2009 20:20 To: Arlt, Juergen (GERST:476S) Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB On Jan 22, 2009, at 10:07 AM, Juergen Arlt wrote: > I have a router that is connected over the WAN to another one. It is > talking OSPF over that link. The interface uses unnumbered IP > (0.0.0.0) > and is therefore using an associated IP - which is in fact the IP of > another interface on the same box. > This associated IP interface has NO OSPF configured. So this interface > should it should not appear in the LSDB. > > In the LSDB however I can see them because the router assumes the > associate address on the point to point link and on that link there is > OPSF. > > Is this correct? How should OSPF announce an unnumbered point to point > link? Should this network be announced at all? Which address shall be > used to announce? An unnumbered link without a full adjacency will not result in any links in the router LSA. Thanks, Acee > > Thanks > Juergen Arlt > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 23 00:37:36 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 03B3C3A6997; Fri, 23 Jan 2009 00:37:36 -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 07ABB28C167 for ; Fri, 23 Jan 2009 00:37:35 -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 CN51-ERXKw-u for ; Fri, 23 Jan 2009 00:37:34 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id E63C13A68AA for ; Fri, 23 Jan 2009 00:37:33 -0800 (PST) Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0N8b5718321; Fri, 23 Jan 2009 08:37:06 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Jan 2009 08:36:59 -0000 Message-ID: In-Reply-To: <67C6601D607D4EF6B739FDB833BC984F@homexpc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] How to announce an unnumbered PtP link in the LSDB Thread-Index: Acl8/D+/MAMKryrsS7+QtBYkKSvmQQANlskgAAA4cSAAAGFEoA== References: <14842AE7A5944227B77EE637E169CA29@homexpc><555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <67C6601D607D4EF6B739FDB833BC984F@homexpc> From: "Juergen Arlt" To: "Sean Andersen" , "Acee Lindem" Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB 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 Thanks for the answer but let me clarify the situation: The routers on the unnumbered links are in full state. As the link is a PtP link it would under normal circumstances (with numbered IP addressing) appear in the router LSA. But in my case the PtP link is unnumbered. What would be the representation in the LSDB of that PtP link? Will there be the address of the associated IP in the LSDB for that PtP link even though the associated IP has no OSPF configured on its real interface? Hope that is clearer. Thanks Juergen -----Original Message----- From: Sean Andersen [mailto:farshad@onebox.com] Sent: Freitag, 23. Januar 2009 09:23 To: Arlt, Juergen (GERST:476S); 'Acee Lindem' Cc: ospf@ietf.org Subject: RE: [OSPF] How to announce an unnumbered PtP link in the LSDB Juergen, Their state is full (as oppose to two way, etc.). That's what Acee is saying. Sean -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Juergen Arlt Sent: Friday, January 23, 2009 12:16 AM To: Acee Lindem Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB Thanks for the answer - is that documented somewhere? And how do you mean without a full adjacency. Aren't the two devices on that point to point link always adjacent? Thanks -----Original Message----- From: Acee Lindem [mailto:acee@redback.com] Sent: Donnerstag, 22. Januar 2009 20:20 To: Arlt, Juergen (GERST:476S) Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB On Jan 22, 2009, at 10:07 AM, Juergen Arlt wrote: > I have a router that is connected over the WAN to another one. It is > talking OSPF over that link. The interface uses unnumbered IP > (0.0.0.0) > and is therefore using an associated IP - which is in fact the IP of > another interface on the same box. > This associated IP interface has NO OSPF configured. So this interface > should it should not appear in the LSDB. > > In the LSDB however I can see them because the router assumes the > associate address on the point to point link and on that link there is > OPSF. > > Is this correct? How should OSPF announce an unnumbered point to point > link? Should this network be announced at all? Which address shall be > used to announce? An unnumbered link without a full adjacency will not result in any links in the router LSA. Thanks, Acee > > Thanks > Juergen Arlt > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 23 00:53:23 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 11C923A6997; Fri, 23 Jan 2009 00:53:23 -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 4907C3A6997 for ; Fri, 23 Jan 2009 00:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=0.832, 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 LMNPKOW4DU8j for ; Fri, 23 Jan 2009 00:53:21 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 30B9A3A697E for ; Fri, 23 Jan 2009 00:53:20 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2009 09:53:02 +0100 In-Reply-To: References: <14842AE7A5944227B77EE637E169CA29@homexpc><555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <67C6601D607D4EF6B739FDB833BC984F@homexpc> To: "Juergen Arlt" MIME-Version: 1.0 X-KeepSent: CC2DC0CF:93122723-C1257547:0030A0A5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Fri, 23 Jan 2009 09:53:02 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-23 09:52:49, Serialize complete at 2009-01-23 09:52:49 X-OriginalArrivalTime: 23 Jan 2009 08:53:02.0733 (UTC) FILETIME=[FFEF83D0:01C97D37] Cc: ospf@ietf.org Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB 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 > > Thanks for the answer but let me clarify the situation: > > The routers on the unnumbered links are in full state. As the link is a > PtP link it would under normal circumstances (with numbered IP > addressing) appear in the router LSA. > But in my case the PtP link is unnumbered. What would be the > representation in the LSDB of that PtP link? > Will there be the address of the associated IP in the LSDB for that PtP > link even though the associated IP has no OSPF configured on its real > interface? You will have ifIndex instead of address and no Option 1 nor Option 2 Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 23 01:07:38 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 667753A697E; Fri, 23 Jan 2009 01:07:38 -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 7029A3A6997 for ; Fri, 23 Jan 2009 01:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[AWL=2.162, BAYES_50=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 qha1F6fdmkTd for ; Fri, 23 Jan 2009 01:07:36 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 389D53A68F7 for ; Fri, 23 Jan 2009 01:07:36 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDX00HXE2O5TL@szxga04-in.huawei.com> for ospf@ietf.org; Fri, 23 Jan 2009 17:07:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDX00I922O5EY@szxga04-in.huawei.com> for ospf@ietf.org; Fri, 23 Jan 2009 17:07:17 +0800 (CST) Received: from HTIPL108071671 ([10.18.23.113]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDX00LKF2O3SB@szxml04-in.huawei.com> for ospf@ietf.org; Fri, 23 Jan 2009 17:07:17 +0800 (CST) Date: Fri, 23 Jan 2009 14:37:15 +0530 From: Abhijit Chaudhary To: ospf@ietf.org Message-id: <002801c97d39$fca88440$7117120a@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 X-Priority: 3 X-MSMail-priority: Normal References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> Subject: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi, According to RFC 2328, if a new router with higher priority is added to the broadcast/NBMA network, it cannot become DR if DR and BDR already exists for the network. This is done to avoid route-calculation, advertisement of new LSA and temporary loss of data traffic. But in some scenario, it may be desirable to make the new router as DR because the new router has an upgraded software, has higher horse-power (more memory, ...) and the existing DR is unable to take any more load of the network. In such scenario, is there any procedure to dynamically select the new router as the DR without manually changing the configuration of the existing DR and BDR? Does any other RFC define such a procedure? Thanks, - Abhijit . _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 23 07:54:03 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 0EBBC3A687B; Fri, 23 Jan 2009 07:54:03 -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 6A09D3A686C for ; Fri, 23 Jan 2009 07:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 cLHFEi2ENXlU for ; Fri, 23 Jan 2009 07:54:00 -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 75B753A687B for ; Fri, 23 Jan 2009 07:54:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QOO4yNjOKgOLAiGMD1wnKX4rTJM7p4x/TxZaOgPomMg6NQtIT6XZtnPqi4r5ttZy; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.219.3] by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LQOLm-0000L3-H0; Fri, 23 Jan 2009 10:53:43 -0500 Message-ID: <4979E864.4020908@earthlink.net> Date: Fri, 23 Jan 2009 07:55:16 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abhijit Chaudhary References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> In-Reply-To: <002801c97d39$fca88440$7117120a@china.huawei.com> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478e6c433f677873d40bc9a9f0552115de7d6c243459f46c23b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.219.3 Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Abhijit, The reason you give below is exactly why in the MANET extension called OSPF-MDR, router priority is given precedence over the existing DR (or MDR) status when a router decides whether it should be a DR (or MDR). I think a simple backward compatible modification for OSPF is for a DR to simply change its interface state to DR Other or Backup if it has a neighbor with a larger router priority. The neighbor will then select itself as a DR. (If this results in two Backup DRs, one of them will change its state to DR Other.) Similarly, a Backup DR can change its interface state to Other if it has two neighbors with a larger router priority. Someone can correct me if I am wrong. Richard Abhijit Chaudhary wrote: > Hi, > According to RFC 2328, if a new router with higher priority is added > to the broadcast/NBMA network, it cannot become DR if DR and BDR > already exists for the network. This is done to avoid > route-calculation, advertisement of new LSA and temporary loss of data > traffic. > But in some scenario, it may be desirable to make the new router as DR > because the new router has an upgraded software, has higher > horse-power (more memory, ...) and the existing DR is unable to take > any more load of the network. > In such scenario, is there any procedure to dynamically select the new > router as the DR without manually changing the configuration of the > existing DR and BDR? Does any other RFC define such a procedure? > > Thanks, > - Abhijit > . > > _______________________________________________ > 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 Fri Jan 23 08:47:34 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 5AB003A68D7; Fri, 23 Jan 2009 08:47:34 -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 C01803A6880 for ; Fri, 23 Jan 2009 08:47:32 -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 0NJJtluNbFWC for ; Fri, 23 Jan 2009 08:47:25 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 5E74D3A68D7 for ; Fri, 23 Jan 2009 08:47:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SlVfsD7pGGPeSE8whNGh+8G4pQ0MFlWs2e2mhV7CefaVdGUBjsTSbxtaO+dVM5Ap; h=Received:From:To:In-Reply-To:Subject:X-Priority:References:Message-Id:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Cc:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [74.95.9.18] (helo=[172.21.1.234]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1LQPBU-0005nB-2W; Fri, 23 Jan 2009 11:47:08 -0500 From: Mitchell Erblich To: Abhijit Chaudhary In-Reply-To: <002801c97d39$fca88440$7117120a@china.huawei.com> X-Priority: 3 References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> Message-Id: <1E9859AD-D9FD-437D-ABAB-484C741955CA@earthlink.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 23 Jan 2009 08:47:04 -0800 X-Mailer: Apple Mail (2.929.2) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79db151e51d29d20b9555dd9cae8a1be6d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 74.95.9.18 Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Abhjit, IF A DR were to be changed, the overhead of doing this change, can be more substantial than creating adjancies from scratch and during such a rollover AND during the change routing loops or DOS or eqivs are expected. THat said, the RFCs allow joining of areas where different DRs exist and re-electing a DR. THus in the simplest idea snoop the advertised priority and announce oneself as a DR with a higher priority. Mitchell Erblich =============== On Jan 23, 2009, at 1:07 AM, Abhijit Chaudhary wrote: > Hi, > According to RFC 2328, if a new router with higher priority is added > to the broadcast/NBMA network, it cannot become DR if DR and BDR > already exists for the network. This is done to avoid route- > calculation, advertisement of new LSA and temporary loss of data > traffic. > But in some scenario, it may be desirable to make the new router as > DR because the new router has an upgraded software, has higher horse- > power (more memory, ...) and the existing DR is unable to take any > more load of the network. > In such scenario, is there any procedure to dynamically select the > new router as the DR without manually changing the configuration of > the existing DR and BDR? Does any other RFC define such a procedure? > > Thanks, > - Abhijit > . > > _______________________________________________ > 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 Fri Jan 23 08:50:50 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 0411528C1E5; Fri, 23 Jan 2009 08:50:50 -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 1A33628C1DE for ; Fri, 23 Jan 2009 08:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 r8-gCxOygDHq for ; Fri, 23 Jan 2009 08:50:47 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id E36F828C17F for ; Fri, 23 Jan 2009 08:50:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=H3BJeba6/0FEsFM6WNsD5+S4wwrR+ANrMOefriAVqiBY70VyUmMFFL5aWLNa1Zs3; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.219.3] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LQPEj-0003OJ-Fi; Fri, 23 Jan 2009 11:50:30 -0500 Message-ID: <4979F5B3.60807@earthlink.net> Date: Fri, 23 Jan 2009 08:52:03 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abhijit Chaudhary References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> In-Reply-To: <002801c97d39$fca88440$7117120a@china.huawei.com> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478e6c433f677873d40b9398ad07f663dcbb1fa21eebbd81fd9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.219.3 Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org I need to update the modification I suggested earlier. The problem is that in the DR election algorithm, an existing BDR is preferred over an Other for becoming a DR, regardless of router priority. Therefore, both the DR and the BDR must change their states to Other if they see an Other that has higher router priority. Hopefully, the following modification works and is backward compatible. If a DR has a neighbor with a larger router priority, then it changes itself to an Other and runs the DR election algorithm. If a BDR has a non-DR neighbor with a larger router priority, then it changes itself to an Other and runs the DR election algorithm. Richard Abhijit Chaudhary wrote: > Hi, > According to RFC 2328, if a new router with higher priority is added > to the broadcast/NBMA network, it cannot become DR if DR and BDR > already exists for the network. This is done to avoid > route-calculation, advertisement of new LSA and temporary loss of data > traffic. > But in some scenario, it may be desirable to make the new router as DR > because the new router has an upgraded software, has higher > horse-power (more memory, ...) and the existing DR is unable to take > any more load of the network. > In such scenario, is there any procedure to dynamically select the new > router as the DR without manually changing the configuration of the > existing DR and BDR? Does any other RFC define such a procedure? > > Thanks, > - Abhijit > . > > _______________________________________________ > 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 Fri Jan 23 10:07:52 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 DA6AB3A6B00; Fri, 23 Jan 2009 10:07:52 -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 8FEC83A6AF6 for ; Fri, 23 Jan 2009 10:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 s5WIj0rm4yrt for ; Fri, 23 Jan 2009 10:07:50 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id BAF273A6832 for ; Fri, 23 Jan 2009 10:07:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4EC4C4CC1B5; Fri, 23 Jan 2009 10:07:34 -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 13764-01; Fri, 23 Jan 2009 10:07:34 -0800 (PST) Received: from [IPv6???1] (lxlogin-2-300.redback.com [155.53.12.217]) by prattle.redback.com (Postfix) with ESMTP id C77374CC1B3; Fri, 23 Jan 2009 10:07:33 -0800 (PST) In-Reply-To: <4979F5B3.60807@earthlink.net> References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Acee Lindem Date: Fri, 23 Jan 2009 13:07:32 -0500 To: Richard Ogier X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote: > I need to update the modification I suggested earlier. > The problem is that in the DR election algorithm, an existing > BDR is preferred over an Other for becoming a DR, regardless > of router priority. Therefore, both the DR and the BDR must > change their states to Other if they see an Other that has > higher router priority. Hopefully, the following modification > works and is backward compatible. I believe a router supporting the proposed "DR preemption" would simply need to advertise itself as backup-DR to force a NeighborChange event on in other OSPF routers on the network. Thanks, Acee > > If a DR has a neighbor with a larger router priority, then it > changes itself to an Other and runs the DR election algorithm. > > If a BDR has a non-DR neighbor with a larger router priority, then it > changes itself to an Other and runs the DR election algorithm. > Richard > > > Abhijit Chaudhary wrote: > >> Hi, >> According to RFC 2328, if a new router with higher priority is >> added to the broadcast/NBMA network, it cannot become DR if DR and >> BDR already exists for the network. This is done to avoid route- >> calculation, advertisement of new LSA and temporary loss of data >> traffic. >> But in some scenario, it may be desirable to make the new router >> as DR because the new router has an upgraded software, has higher >> horse-power (more memory, ...) and the existing DR is unable to >> take any more load of the network. >> In such scenario, is there any procedure to dynamically select the >> new router as the DR without manually changing the configuration >> of the existing DR and BDR? Does any other RFC define such a >> procedure? >> >> Thanks, >> - Abhijit >> . >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 23 11:05:17 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 629F528C0F9; Fri, 23 Jan 2009 11:05:17 -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 A24DC28C15B for ; Fri, 23 Jan 2009 11:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 vwCkF81byO38 for ; Fri, 23 Jan 2009 11:05:08 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 989E63A6814 for ; Fri, 23 Jan 2009 11:05:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=d8RPxpl9MHkZs/HTmcfbYDAf4DGoQJjWlx+Ylr/kaU3vyfxyKZYgVv63CIvknfF6; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.221.54] by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LQRKk-0004Ee-2D; Fri, 23 Jan 2009 14:04:51 -0500 Message-ID: <497A152D.9050006@earthlink.net> Date: Fri, 23 Jan 2009 11:06:21 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> In-Reply-To: X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478e6c433f677873d4095a32867eb8b5cc1195b14a682a58f90350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.54 Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Acee Lindem wrote: > > On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote: > >> I need to update the modification I suggested earlier. >> The problem is that in the DR election algorithm, an existing >> BDR is preferred over an Other for becoming a DR, regardless >> of router priority. Therefore, both the DR and the BDR must >> change their states to Other if they see an Other that has >> higher router priority. Hopefully, the following modification >> works and is backward compatible. > > > I believe a router supporting the proposed "DR preemption" would > simply need to advertise itself as backup-DR to force a > NeighborChange event on in other OSPF routers on the network. But this is not enough if there is an Other that has the largest router priority. The Other would still not promote itself to BDR or DR since it has a BDR neighbor (the one you refer to above). Also, when the new BDR runs the DR election algorithm again, it will promote itself back to a DR. That is why I am suggesting the following rules: If a DR has a neighbor with a larger router priority, then it changes itself to an Other (and advertises itself as such). If a BDR has a non-DR neighbor with a larger router priority, then it changes itself to an Other (and advertises itself as such). Otherwise, the DR election algorithm is run as usual. Richard > > Thanks, > Acee > > > > > > > > >> >> If a DR has a neighbor with a larger router priority, then it >> changes itself to an Other and runs the DR election algorithm. >> >> If a BDR has a non-DR neighbor with a larger router priority, then it >> changes itself to an Other and runs the DR election algorithm. >> Richard >> >> >> Abhijit Chaudhary wrote: >> >>> Hi, >>> According to RFC 2328, if a new router with higher priority is >>> added to the broadcast/NBMA network, it cannot become DR if DR and >>> BDR already exists for the network. This is done to avoid route- >>> calculation, advertisement of new LSA and temporary loss of data >>> traffic. >>> But in some scenario, it may be desirable to make the new router as >>> DR because the new router has an upgraded software, has higher >>> horse-power (more memory, ...) and the existing DR is unable to >>> take any more load of the network. >>> In such scenario, is there any procedure to dynamically select the >>> new router as the DR without manually changing the configuration of >>> the existing DR and BDR? Does any other RFC define such a procedure? >>> >>> Thanks, >>> - Abhijit >>> . >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jan 23 11:46:15 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 1FF033A6B10; Fri, 23 Jan 2009 11:46:15 -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 BAE2F3A69AB for ; Fri, 23 Jan 2009 11:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=0.799, 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 JcFoYJ1PFzHu for ; Fri, 23 Jan 2009 11:46:13 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 902F53A6B21 for ; Fri, 23 Jan 2009 11:46:11 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2009 20:45:50 +0100 In-Reply-To: References: To: Joakim Tjernlund MIME-Version: 1.0 X-KeepSent: B94B5809:59DE8B2D-C1257547:006C5A55; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Fri, 23 Jan 2009 20:45:50 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-23 20:45:36, Serialize complete at 2009-01-23 20:45:36 X-OriginalArrivalTime: 23 Jan 2009 19:45:50.0231 (UTC) FILETIME=[31956A70:01C97D93] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 > > Dave Katz wrote on 20/01/2009 20:42:09: > > > > On Jan 20, 2009, at 12:12 PM, Joakim Tjernlund wrote: > > > > >> But for what it's worth, for most implementations, point-to-point > > >> links have no next-hop address, so the issue is moot. This avoids > > >> the > > >> issue of having to know or care whether the far end is numbered or > > >> unnumbered. > > > > > > But PtoP links can have an IP address and if they do, should link type > > > 1 be considered? > > > > If you're only installing an interface nexthop, why would you care? > > > > If you want to come up with a next hop address, you have the side > > issue you touched on earlier, which is trying to discern whether the > > far end is numbered (in which case the link data would be the next hop > > address) or unnumbered (in which case the link data would be an > > interface index that means nothing to you.) Other than attempting to > > apply heuristics to the data to find out if it is an interface index > > or not (I don't remember whether SNMP defined indices as something > > less than 32 bits; if not, there is no heuristic that can work) the > > only choice is to look at your own numbered/unnumbered configuration > > and hope the other guy is set up the same way. > > > > It all gets tricky when there are multiple links between pairs of > > systems as well, as you need to correlate the LSAs to interfaces... > > OK, I understand. No need to supply a next hop address for PtoP links. > I still got a problem though :( > > The text "for each link in the router-LSA that points back > to the parent network" is where I still got a problem. > How do I find the correct ones? Since router ID and Interface address > may have the same value, I cant just match Network vertex ID against > every entry in the Router LSA. > Since the parent vertex is a network, I figured that the only thing I > can match is the Network vertex ID against is link ID in link type 2 > (Link to transit network) and use the link data is nexthop address. > The text says that each link should "point back to the parent network" > and that implies to me that you should only consider links that is > attached > to a network and to me PtoP links never points to a network so one should > exclude > PtoP links as possible nexthops. > > I am probably very confused so if you could give me a clue or two, > I would be very grateful. > > Jocke Ping, any clues to my ranting above? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From jlondon@alisarah.freeserve.co.uk Fri Jan 23 15:56:28 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD993A6895 for ; Fri, 23 Jan 2009 15:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.633 X-Spam-Level: X-Spam-Status: No, score=-41.633 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] 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 04U8--gxWkBa for ; Fri, 23 Jan 2009 15:56:27 -0800 (PST) Received: from 200-96-219-75.pvoce701.dsl.brasiltelecom.net.br (200-96-219-75.pvoce701.dsl.brasiltelecom.net.br [200.96.219.75]) by core3.amsl.com (Postfix) with SMTP id 99BEB3A6833 for ; Fri, 23 Jan 2009 15:56:24 -0800 (PST) To: Subject: Important Information From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090123235625.99BEB3A6833@core3.amsl.com> Date: Fri, 23 Jan 2009 15:56:24 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Click Here!

To unsubscribe from this mailing list, please log in to www.eventafter.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://eventafter.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 3, B965. 567 Clements Road. London. SE35 2DG

© 2006-2009 BRANDKEYWORD, Ltd. All Rights Reserved

From ospf-bounces@ietf.org Fri Jan 23 16:29:09 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 ED1313A6851; Fri, 23 Jan 2009 16:29:08 -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 8E4AF3A6851 for ; Fri, 23 Jan 2009 16:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 oX6mvA86Dv1q for ; Fri, 23 Jan 2009 16:29:06 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 5F0843A67F9 for ; Fri, 23 Jan 2009 16:29:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSXpgt/cT/iQ24YGtY4tE1DMWdzYQ5+DF@postini.com; Fri, 23 Jan 2009 16:28:50 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.336.0; Fri, 23 Jan 2009 16:27:25 -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); Fri, 23 Jan 2009 16:27:24 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 16:27:24 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 16:27:24 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0O0RNM80481; Fri, 23 Jan 2009 16:27:23 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <35D8C179-9F6A-4690-9904-E750FD314118@juniper.net> From: Dave Katz To: Joakim Tjernlund In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 23 Jan 2009 17:27:22 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Jan 2009 00:27:24.0056 (UTC) FILETIME=[87168980:01C97DBA] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 On Jan 23, 2009, at 12:45 PM, Joakim Tjernlund wrote: >> >> OK, I understand. No need to supply a next hop address for PtoP >> links. >> I still got a problem though :( >> >> The text "for each link in the router-LSA that points back >> to the parent network" is where I still got a problem. >> How do I find the correct ones? Since router ID and Interface address >> may have the same value, I cant just match Network vertex ID against >> every entry in the Router LSA. >> >> Since the parent vertex is a network, I figured that the only thing I >> can match is the Network vertex ID against is link ID in link type 2 >> (Link to transit network) and use the link data is nexthop address. >> The text says that each link should "point back to the parent >> network" >> and that implies to me that you should only consider links that is >> attached >> to a network and to me PtoP links never points to a network so one > should >> exclude >> PtoP links as possible nexthops. I'm pretty confused about your confusion, though one of them seems to be mixing up "network" and "network LSA" which are not the same thing. The paragraph applies to either type 1 or type 2 links. The interface IP address of the next-hop router will never be the same for multiple links, as it would imply the same subnet assigned to two networks, so this disambiguates parallel numbered links. In the case of numbered point-to-point links, it's trivial. Find every link in the neighbor's LSA with your own router ID and grab the next-hop address out of the associated link data. Sort out which interface each address belongs to, and you've got your next hop (you don't actually need the address.) For the LAN/NBMA case you find the link that matches the network LSA you're looking through to see the router LSA, which tells you the interface, and the link data specifies the next hop address. For unnumbered links you cannot actually disambiguate parallel links, but it doesn't really matter. The next hop interface(s) are those matching the interface index in the local router LSA, with no next hop addresses. --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From kimberlee.stiles@ameristar.com Fri Jan 23 17:15:52 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CBE93A68B4 for ; Fri, 23 Jan 2009 17:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.311 X-Spam-Level: X-Spam-Status: No, score=-40.311 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 NBgawzifpcUk for ; Fri, 23 Jan 2009 17:15:51 -0800 (PST) Received: from 200-207-179-174.dial-up.telesp.net.br (200-207-179-174.dial-up.telesp.net.br [200.207.179.174]) by core3.amsl.com (Postfix) with SMTP id E8F7D3A67F3 for ; Fri, 23 Jan 2009 17:15:49 -0800 (PST) To: Subject: Mail could not be delivered From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 090123-0, 23/01/2009), Outbound message X-Antivirus-Status: Clean Message-Id: <20090124011549.E8F7D3A67F3@core3.amsl.com> Date: Fri, 23 Jan 2009 17:15:49 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Click Here!

To unsubscribe from this mailing list, please log in to www.growgenerosity.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://growgenerosity.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 8, B791. 547 Clements Road. London. SE58 4DG

© 2006-2009 BRANDKEYWORD, Ltd. All Rights Reserved

From ospf-bounces@ietf.org Fri Jan 23 17:58:35 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 4A0743A694D; Fri, 23 Jan 2009 17:58:35 -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 9AE823A694D for ; Fri, 23 Jan 2009 17:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 HrszGvsOyy9d for ; Fri, 23 Jan 2009 17:58:32 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id A41563A67C1 for ; Fri, 23 Jan 2009 17:58:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rqlgkpqDt6CcjOxR9up91aZHI0xyneUSllD6fPsA3Yd2L3dLRoVRor4WaD7sxMo7; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.219.211] by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LQXml-0000if-Kg; Fri, 23 Jan 2009 20:58:12 -0500 Message-ID: <497A7611.7090300@earthlink.net> Date: Fri, 23 Jan 2009 17:59:45 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> In-Reply-To: X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478e6c433f677873d4084ed90c801741e2df76fb537681c8db9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.219.211 Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Acee Lindem wrote: > > On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote: > >> I need to update the modification I suggested earlier. >> The problem is that in the DR election algorithm, an existing >> BDR is preferred over an Other for becoming a DR, regardless >> of router priority. Therefore, both the DR and the BDR must >> change their states to Other if they see an Other that has >> higher router priority. Hopefully, the following modification >> works and is backward compatible. > > > I believe a router supporting the proposed "DR preemption" would > simply need to advertise itself as backup-DR to force a > NeighborChange event on in other OSPF routers on the network. As you suggest, it would be better to have the DR change to a BDR, rather than a DR Other, when possible. It may be possible to do this if the router with larger router priority is not a DR Other. The following rules might achieve this. 1. If the router is DR or BDR and has a DR Other neighbor with a larger router priority, then it changes itself to DR Other. 2. Otherwise, if the router is DR and has a BDR neighbor with a larger router priority, then it changes itself to BDR. If step 2 is executed, then the neighboring BDR with larger router priority will soon change its state to DR. Hopefully, this will happen before the the next time the router itself runs the DR election algorithm. If not, then the router will change its state to DR Other temporarily, and then back to BDR. To avoid this, I think the DR election algorithm can be modified so that a BDR can remain a BDR if there is no DR and only one BDR neighbor has a lexicographically larger value of (RtrPri, RID). Obviously, some details need to be worked out. Richard > > Thanks, > Acee > > >> >> If a DR has a neighbor with a larger router priority, then it >> changes itself to an Other and runs the DR election algorithm. >> >> If a BDR has a non-DR neighbor with a larger router priority, then it >> changes itself to an Other and runs the DR election algorithm. >> Richard >> >> >> Abhijit Chaudhary wrote: >> >>> Hi, >>> According to RFC 2328, if a new router with higher priority is >>> added to the broadcast/NBMA network, it cannot become DR if DR and >>> BDR already exists for the network. This is done to avoid route- >>> calculation, advertisement of new LSA and temporary loss of data >>> traffic. >>> But in some scenario, it may be desirable to make the new router as >>> DR because the new router has an upgraded software, has higher >>> horse-power (more memory, ...) and the existing DR is unable to >>> take any more load of the network. >>> In such scenario, is there any procedure to dynamically select the >>> new router as the DR without manually changing the configuration of >>> the existing DR and BDR? Does any other RFC define such a procedure? >>> >>> Thanks, >>> - Abhijit >>> . >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From malgorzatamszuppem@amrest.com.pl Sat Jan 24 02:45:24 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9213A6980 for ; Sat, 24 Jan 2009 02:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.062 X-Spam-Level: X-Spam-Status: No, score=-38.062 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_HU=1.35, HELO_MISMATCH_HU=2.443, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 6bpavKcNwjh2 for ; Sat, 24 Jan 2009 02:45:24 -0800 (PST) Received: from aktivrekord.hu (unknown [88.246.253.49]) by core3.amsl.com (Postfix) with SMTP id 58C3F3A67B5 for ; Sat, 24 Jan 2009 02:45:20 -0800 (PST) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124104522.58C3F3A67B5@core3.amsl.com> Date: Sat, 24 Jan 2009 02:45:20 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.progressfavor.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://progressfavor.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 4, B434. 415 Clements Road. London. SE55 6DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From leehuessener@agedwards.com Sat Jan 24 06:23:09 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8EB3A6A08 for ; Sat, 24 Jan 2009 06:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.987 X-Spam-Level: X-Spam-Status: No, score=-24.987 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] 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 RK0WD6H3sUPV for ; Sat, 24 Jan 2009 06:23:08 -0800 (PST) Received: from 93-120-178-152.dynamic.mts-nn.ru (93-120-161-19.dynamic.mts-nn.ru [93.120.161.19]) by core3.amsl.com (Postfix) with SMTP id 73EE63A6B2C for ; Sat, 24 Jan 2009 06:23:05 -0800 (PST) To: Subject: Welcome to eBay! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124142306.73EE63A6B2C@core3.amsl.com> Date: Sat, 24 Jan 2009 06:23:05 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.progressfavor.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://progressfavor.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B427. 535 Clements Road. London. SE46 5DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From mjleon@aena.es Sat Jan 24 07:04:05 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D7128C148 for ; Sat, 24 Jan 2009 07:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.855 X-Spam-Level: X-Spam-Status: No, score=-25.855 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] 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 6sPtJ08kwnjQ for ; Sat, 24 Jan 2009 07:04:00 -0800 (PST) Received: from aag.org.ec (unknown [122.169.187.29]) by core3.amsl.com (Postfix) with SMTP id 327763A6781 for ; Sat, 24 Jan 2009 07:03:57 -0800 (PST) To: Subject: PayPal - Email Handling Opinion Needed From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124150358.327763A6781@core3.amsl.com> Date: Sat, 24 Jan 2009 07:03:57 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.oppositereciprocity.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://oppositereciprocity.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 4, B622. 427 Clements Road. London. SE55 4DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From kiis@agco.com.ar Sat Jan 24 07:55:15 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A1C28C0E5 for ; Sat, 24 Jan 2009 07:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.068 X-Spam-Level: X-Spam-Status: No, score=-44.068 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 PSrSQk0h9LgP for ; Sat, 24 Jan 2009 07:55:13 -0800 (PST) Received: from 60-228-113-92.pool.ukrtel.net (63-241-113-92.pool.ukrtel.net [92.113.241.63]) by core3.amsl.com (Postfix) with SMTP id 67C1B3A68D2 for ; Sat, 24 Jan 2009 07:55:10 -0800 (PST) To: Subject: Mail could not be delivered From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124155512.67C1B3A68D2@core3.amsl.com> Date: Sat, 24 Jan 2009 07:55:10 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
0531 W. Abram St. City, Arlington


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From ospf-bounces@ietf.org Sat Jan 24 12:22:52 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 BA92C28B797; Sat, 24 Jan 2009 12:22:52 -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 E07D728B797 for ; Sat, 24 Jan 2009 12:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=0.768, 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 w9OHRUjQyxwV for ; Sat, 24 Jan 2009 12:22:50 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 377233A6967 for ; Sat, 24 Jan 2009 12:22:49 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Jan 2009 21:22:26 +0100 In-Reply-To: <35D8C179-9F6A-4690-9904-E750FD314118@juniper.net> References: <35D8C179-9F6A-4690-9904-E750FD314118@juniper.net> To: Dave Katz MIME-Version: 1.0 X-KeepSent: D7630A5A:55CD56DC-C1257548:006D74FB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Sat, 24 Jan 2009 21:22:25 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-24 21:22:11, Serialize complete at 2009-01-24 21:22:11 X-OriginalArrivalTime: 24 Jan 2009 20:22:26.0848 (UTC) FILETIME=[79485200:01C97E61] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 Dave Katz wrote on 24/01/2009 01:27:22: > On Jan 23, 2009, at 12:45 PM, Joakim Tjernlund wrote: > >> > >> OK, I understand. No need to supply a next hop address for PtoP > >> links. > >> I still got a problem though :( > >> > >> The text "for each link in the router-LSA that points back > >> to the parent network" is where I still got a problem. > >> How do I find the correct ones? Since router ID and Interface address > >> may have the same value, I cant just match Network vertex ID against > >> every entry in the Router LSA. > >> > >> Since the parent vertex is a network, I figured that the only thing I > >> can match is the Network vertex ID against is link ID in link type 2 > >> (Link to transit network) and use the link data is nexthop address. > >> The text says that each link should "point back to the parent > >> network" > >> and that implies to me that you should only consider links that is > >> attached > >> to a network and to me PtoP links never points to a network so one > > should > >> exclude > >> PtoP links as possible nexthops. > > I'm pretty confused about your confusion, though one of them seems to > be mixing up "network" and "network LSA" which are not the same > thing. The paragraph applies to either type 1 or type 2 links. > > The interface IP address of the next-hop router will never be the same > for multiple links, as it would imply the same subnet assigned to two > networks, so this disambiguates parallel numbered links. > > In the case of numbered point-to-point links, it's trivial. Find > every link in the neighbor's LSA with your own router ID and grab the > next-hop address out of the associated link data. Sort out which > interface each address belongs to, and you've got your next hop (you > don't actually need the address.) > > For the LAN/NBMA case you find the link that matches the network LSA > you're looking through to see the router LSA, which tells you the > interface, and the link data specifies the next hop address. > > For unnumbered links you cannot actually disambiguate parallel links, > but it doesn't really matter. The next hop interface(s) are those > matching the interface index in the local router LSA, with no next hop > addresses. Nice, this was useful info, but I still don't get why PtP links are considered is this case. Here is why: Input to this function is a parent vertex and a destination vertex. In this case the parent vertex must be a Network vertex and the destination vertex is a Router vertex. This Figure illustrates what I think this case is about: CR -- N -- DR CR = Calculating Router N = Network in question DR = Destination Router We are looking at N, a network vertex who is directly connected to the calculating router, CR. The destination is DR is also connected to N. No Ptp or PtMP is connected to a Network vertex, only LAN/NBMA are. So the only link type that you should look for is type 2 that point back to you and use its link_data as next hop. Also, this paragraph mentions that you can inherit the outgoing interface from the parent. I think this means that you don't have to look for it as you describe above, just use the interface from the parent directly, or do I misunderstand? I really need an example on how PtP links fits into this, I can't see it. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Jan 24 16:07:15 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 A89083A6B48; Sat, 24 Jan 2009 16:07:15 -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 1E6DA3A6B48 for ; Sat, 24 Jan 2009 16:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 Gm4lSN+TfT2U for ; Sat, 24 Jan 2009 16:07:14 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 1D7483A6AC3 for ; Sat, 24 Jan 2009 16:07:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=q9XsMAZSQJ6Zn/DvHyyL2BUmzOehYj5oVp5AzDG9yYkmoua0vV4dMSwQ4s2i8HbO; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.221.205] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LQsWa-0000bd-IJ; Sat, 24 Jan 2009 19:06:54 -0500 Message-ID: <497BAD7C.8060604@earthlink.net> Date: Sat, 24 Jan 2009 16:08:28 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joakim Tjernlund References: <35D8C179-9F6A-4690-9904-E750FD314118@juniper.net> In-Reply-To: X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478e6c433f677873d4038a67b212cc87a88c4c5dbd65be3b663350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.205 Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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: multipart/mixed; boundary="===============2006578109==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============2006578109== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Joakim Tjernlund wrote: 
Dave Katz <dkatz@juniper.net> wrote on 24/01/2009 01:27:22:
  
On Jan 23, 2009, at 12:45 PM, Joakim Tjernlund wrote:
    
OK, I understand. No need to supply a next hop address for PtoP 
links.
I still got a problem though :(

The text "for each link in the router-LSA that points back
to the parent network" is where I still got a problem.
How do I find the correct ones? Since router ID and Interface address
may have the same value, I cant just match Network vertex ID against
every entry in the Router LSA.

Since the parent vertex is a network, I figured that the only thing I
can match is the Network vertex ID against is link ID in link type 2
(Link to transit network) and use the link data is nexthop address.
The text says that each link should "point back to the parent 
network"
and that implies to me that you should only consider links that is
attached
to a network and to me PtoP links never points to a network so one
        
should
      
exclude
PtoP links as possible nexthops.
        
I'm pretty confused about your confusion, though one of them seems to 
be mixing up "network" and "network LSA" which are not the same 
thing.  The paragraph applies to either type 1 or type 2 links.

The interface IP address of the next-hop router will never be the same 
for multiple links, as it would imply the same subnet assigned to two 
networks, so this disambiguates parallel numbered links.

In the case of numbered point-to-point links, it's trivial.  Find 
every link in the neighbor's LSA with your own router ID and grab the 
next-hop address out of the associated link data.  Sort out which 
interface each address belongs to, and you've got your next hop (you 
don't actually need the address.)

For the LAN/NBMA case you find the link that matches the network LSA 
you're looking through to see the router LSA, which tells you the 
interface, and the link data specifies the next hop address.

For unnumbered links you cannot actually disambiguate parallel links, 
but it doesn't really matter.  The next hop interface(s) are those 
matching the interface index in the local router LSA, with no next hop 
addresses.
    

Nice, this was useful info, but I still don't get why PtP links are
considered is this case. Here is why:

Input to this function is a parent vertex and a destination vertex. In 
this
case the parent vertex must be a Network vertex and the destination vertex
is a Router vertex. This Figure illustrates what I think this case is 
about: 
  CR -- N -- DR
 CR = Calculating Router
 N = Network in question
 DR = Destination Router

We are looking at N, a network vertex who is directly connected to the
calculating router, CR. The destination is DR is also connected to N.
No Ptp or PtMP is connected to a Network vertex, only LAN/NBMA are.
So the only link type that you should look for is type 2 that point back
to you and use its link_data as next hop.

Maybe I am missing something, but I am confused why you are requiring
the parent vertex to be a network. Just above the paragraph on page 168
that you quoted, you can find the following sentence:

   "If the destination is a
   directly connected network, or a router which connects to
   the calculating router via a point-to-point interface, no
   next hop IP address is required."

Therefore, for a point-to-point link, the next hop consists only
of the outgoing interface.  Does this answer your question or
am I missing something?

Richard
 
Also, this paragraph mentions that you can inherit the outgoing interface 
from
the parent. I think this means that you don't have to look for it as you 
describe
above, just use the interface from the parent directly, or do I 
misunderstand?

I really need an example on how PtP links fits into this, I can't see it.

 Jocke

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
--===============2006578109== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============2006578109==-- From lenadd@alcyon.com Sun Jan 25 00:01:21 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973613A6452 for ; Sun, 25 Jan 2009 00:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.72 X-Spam-Level: X-Spam-Status: No, score=-16.72 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 uVzLYBZBu6Dx for ; Sun, 25 Jan 2009 00:01:20 -0800 (PST) Received: from 90-154-161-230.btc-net.bg (90-154-161-230.btc-net.bg [90.154.161.230]) by core3.amsl.com (Postfix) with SMTP id C80BC3A6405 for ; Sun, 25 Jan 2009 00:01:19 -0800 (PST) To: Subject: Notification Type: All OK From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090125080119.C80BC3A6405@core3.amsl.com> Date: Sun, 25 Jan 2009 00:01:19 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
259 Taylor Road P.O. Box 9111


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From ospf-bounces@ietf.org Sun Jan 25 00:48:46 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 1B4A328C115; Sun, 25 Jan 2009 00:48:46 -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 76FF828B797 for ; Sun, 25 Jan 2009 00:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 e7jtDN4NVySG for ; Sun, 25 Jan 2009 00:48:43 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 40EFD28C100 for ; Sun, 25 Jan 2009 00:48:41 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSXwnV54bkxw0hhPfV8i7t+muIiNUBMvD@postini.com; Sun, 25 Jan 2009 00:48:26 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.336.0; Sun, 25 Jan 2009 00:44:06 -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, 25 Jan 2009 00:44:06 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Jan 2009 00:44:06 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Jan 2009 00:44:05 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0P8i3M37349; Sun, 25 Jan 2009 00:44:05 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Joakim Tjernlund In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 25 Jan 2009 01:44:01 -0700 References: <35D8C179-9F6A-4690-9904-E750FD314118@juniper.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 25 Jan 2009 08:44:05.0846 (UTC) FILETIME=[14C08F60:01C97EC9] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 When all else fails, just do what makes sense. An SPF that didn't work with point-to-point would make for a pretty disjointed network... --Dave On Jan 24, 2009, at 1:22 PM, Joakim Tjernlund wrote: > Dave Katz wrote on 24/01/2009 01:27:22: >> On Jan 23, 2009, at 12:45 PM, Joakim Tjernlund wrote: >>>> >>>> OK, I understand. No need to supply a next hop address for PtoP >>>> links. >>>> I still got a problem though :( >>>> >>>> The text "for each link in the router-LSA that points back >>>> to the parent network" is where I still got a problem. >>>> How do I find the correct ones? Since router ID and Interface >>>> address >>>> may have the same value, I cant just match Network vertex ID >>>> against >>>> every entry in the Router LSA. >>>> >>>> Since the parent vertex is a network, I figured that the only >>>> thing I >>>> can match is the Network vertex ID against is link ID in link >>>> type 2 >>>> (Link to transit network) and use the link data is nexthop address. >>>> The text says that each link should "point back to the parent >>>> network" >>>> and that implies to me that you should only consider links that is >>>> attached >>>> to a network and to me PtoP links never points to a network so one >>> should >>>> exclude >>>> PtoP links as possible nexthops. >> >> I'm pretty confused about your confusion, though one of them seems to >> be mixing up "network" and "network LSA" which are not the same >> thing. The paragraph applies to either type 1 or type 2 links. >> >> The interface IP address of the next-hop router will never be the >> same >> for multiple links, as it would imply the same subnet assigned to two >> networks, so this disambiguates parallel numbered links. >> >> In the case of numbered point-to-point links, it's trivial. Find >> every link in the neighbor's LSA with your own router ID and grab the >> next-hop address out of the associated link data. Sort out which >> interface each address belongs to, and you've got your next hop (you >> don't actually need the address.) >> >> For the LAN/NBMA case you find the link that matches the network LSA >> you're looking through to see the router LSA, which tells you the >> interface, and the link data specifies the next hop address. >> >> For unnumbered links you cannot actually disambiguate parallel links, >> but it doesn't really matter. The next hop interface(s) are those >> matching the interface index in the local router LSA, with no next >> hop >> addresses. > > Nice, this was useful info, but I still don't get why PtP links are > considered is this case. Here is why: > > Input to this function is a parent vertex and a destination vertex. In > this > case the parent vertex must be a Network vertex and the destination > vertex > is a Router vertex. This Figure illustrates what I think this case is > about: > CR -- N -- DR > CR = Calculating Router > N = Network in question > DR = Destination Router > > We are looking at N, a network vertex who is directly connected to the > calculating router, CR. The destination is DR is also connected to N. > No Ptp or PtMP is connected to a Network vertex, only LAN/NBMA are. > So the only link type that you should look for is type 2 that point > back > to you and use its link_data as next hop. > > Also, this paragraph mentions that you can inherit the outgoing > interface > from > the parent. I think this means that you don't have to look for it as > you > describe > above, just use the interface from the parent directly, or do I > misunderstand? > > I really need an example on how PtP links fits into this, I can't > see it. > > Jocke > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Jan 25 01:34:24 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 E729A3A69C4; Sun, 25 Jan 2009 01:34:24 -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 9062F3A69B8 for ; Sun, 25 Jan 2009 01:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=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 f0LuQfHxY1O7 for ; Sun, 25 Jan 2009 01:34:22 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id 7A3AD3A69A2 for ; Sun, 25 Jan 2009 01:34:21 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Jan 2009 10:34:02 +0100 In-Reply-To: <497BAD7C.8060604@earthlink.net> References: <35D8C179-9F6A-4690-9904-E750FD314118@juniper.net> <497BAD7C.8060604@earthlink.net> To: Richard Ogier MIME-Version: 1.0 X-KeepSent: F2C2B403:8454F873-C1257549:00333169; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Sun, 25 Jan 2009 10:34:01 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-25 10:33:46, Serialize complete at 2009-01-25 10:33:46 X-OriginalArrivalTime: 25 Jan 2009 09:34:02.0931 (UTC) FILETIME=[0F277030:01C97ED0] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 Richard Ogier wrote on 25/01/2009 01:08:28: > > > Maybe I am missing something, but I am confused why you are requiring > the parent vertex to be a network. Just above the paragraph on page 168 > that you quoted, you can find the following sentence: > > "If the destination is a > directly connected network, or a router which connects to > the calculating router via a point-to-point interface, no > next hop IP address is required." > > Therefore, for a point-to-point link, the next hop consists only > of the outgoing interface. Does this answer your question or > am I missing something? > > Richard Ah, now we are getting closer I think. Chapter 16.1.1 is rather big describes 3 cases(the third being the one that doesn't match case 1 or 2 ): If there is at least one intervening router in the current shortest path between the destination and the root, the destination simply inherits the set of next hops from the parent. Otherwise, there are two cases. In the first case, the parent vertex is the root (the calculating router itself). ..... In the second case, the parent vertex is a network that directly connects the calculating router to the destination router. The text you quoted is from the first case and I have no problem with that part and it includes PtP links and both types of vertexes. I have however only asked about the second case, I guess it got lost somewhere. So looking only at the second case, does my theory make sense? Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From mweaaaaa@airinter-msia.com Sun Jan 25 04:55:33 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B803F3A6831 for ; Sun, 25 Jan 2009 04:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.878 X-Spam-Level: X-Spam-Status: No, score=-46.878 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] 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 H8dIYOxtLXRp for ; Sun, 25 Jan 2009 04:55:33 -0800 (PST) Received: from agrosuper.com (unknown [85.98.151.182]) by core3.amsl.com (Postfix) with SMTP id E5AD63A676A for ; Sun, 25 Jan 2009 04:55:28 -0800 (PST) To: Subject: Mail could not be delivered From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090125125529.E5AD63A676A@core3.amsl.com> Date: Sun, 25 Jan 2009 04:55:28 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
3884 Amphitheatre Parkway, Mountain View, CA, 32003, USA.


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From ospf-bounces@ietf.org Sun Jan 25 10:21:25 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 2C7A33A6B57; Sun, 25 Jan 2009 10:21:25 -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 D4E3B28C0F7 for ; Sun, 25 Jan 2009 10:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_HTML_ONLY=1.457] 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 WjNjeRXSm-+Q for ; Sun, 25 Jan 2009 10:21:23 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id E3DC43A6954 for ; Sun, 25 Jan 2009 10:21:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=j+IfXtwJBznGG94PRD7KM6+3R3hhGclRoJXQAaJWeSlgsh9toF6/8KCEevfUH02C; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.217.12] by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LR9bQ-0004SU-EB; Sun, 25 Jan 2009 13:21:01 -0500 Message-ID: <497CADEF.8060102@earthlink.net> Date: Sun, 25 Jan 2009 10:22:39 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joakim Tjernlund References: <35D8C179-9F6A-4690-9904-E750FD314118@juniper.net> <497BAD7C.8060604@earthlink.net> In-Reply-To: X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478e6c433f677873d40dc7ff02ceddea42a1931a1fc8dcca808350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.217.12 Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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: multipart/mixed; boundary="===============1998993993==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1998993993== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Joakim Tjernlund wrote: 
Richard Ogier <ogier@earthlink.net> wrote on 25/01/2009 01:08:28:
  
Maybe I am missing something, but I am confused why you are requiring
the parent vertex to be a network. Just above the paragraph on page 168
that you quoted, you can find the following sentence:

   "If the destination is a
   directly connected network, or a router which connects to
   the calculating router via a point-to-point interface, no
   next hop IP address is required."

Therefore, for a point-to-point link, the next hop consists only
of the outgoing interface.  Does this answer your question or
am I missing something?

Richard
    

Ah, now we are getting closer I think. Chapter 16.1.1 is rather big 
describes
3 cases(the third being the one that doesn't match case 1 or 2 ):

            If there is at least one intervening router in the current
            shortest path between the destination and the root, the
            destination simply inherits the set of next hops from the
            parent.  Otherwise, there are two cases.  In the first case,
            the parent vertex is the root (the calculating router
            itself).
.....
            In the second case, the parent vertex is a network that
            directly connects the calculating router to the destination
            router.

The text you quoted is from the first case and I have no problem with that 
part and
it includes PtP links and both types of vertexes.
I have however only asked about the second case, I guess it got lost 
somewhere.

So looking only at the second case, does my theory make sense?

I think your point was that you don't see how point-to-point links fit
into the second case.  I think the answer is that they don't, since
for point-to-point links, the parent vertex is not a network, but is
the calculating router.  There is no transit network vertex associated
with a point-to-point link.  Thus, a point-to-point link always falls
into the first case, not the second case.  (This seems clear to me,
so I don't know why there was any confusion.)

Richard

 Jocke
--===============1998993993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============1998993993==-- From ospf-bounces@ietf.org Sun Jan 25 10:41:36 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 8B6F03A6954; Sun, 25 Jan 2009 10:41:36 -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 ECBBA3A6954 for ; Sun, 25 Jan 2009 10:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=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 9SQB0c9yr4if for ; Sun, 25 Jan 2009 10:41:34 -0800 (PST) Received: from mail.transmode.se (mail.transmode.se [83.241.175.147]) by core3.amsl.com (Postfix) with ESMTP id D73483A67FF for ; Sun, 25 Jan 2009 10:41:33 -0800 (PST) Received: from webmail.transmode.se ([192.168.201.15]) by mail.transmode.se with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Jan 2009 19:41:14 +0100 In-Reply-To: <497CADEF.8060102@earthlink.net> References: <35D8C179-9F6A-4690-9904-E750FD314118@juniper.net> <497BAD7C.8060604@earthlink.net> <497CADEF.8060102@earthlink.net> To: Richard Ogier MIME-Version: 1.0 X-KeepSent: 8FF9FFF7:CF2B8D3D-C1257549:006659F0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Sun, 25 Jan 2009 19:41:14 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.0.2|August 07, 2008) at 2009-01-25 19:40:57, Serialize complete at 2009-01-25 19:40:57 X-OriginalArrivalTime: 25 Jan 2009 18:41:14.0942 (UTC) FILETIME=[808EBDE0:01C97F1C] Cc: ospf@ietf.org Subject: Re: [OSPF] nexthop 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 Richard Ogier wrote on 25/01/2009 19:22:39: > > Joakim Tjernlund wrote: > Richard Ogier wrote on 25/01/2009 01:08:28: > > > Maybe I am missing something, but I am confused why you are requiring > the parent vertex to be a network. Just above the paragraph on page 168 > that you quoted, you can find the following sentence: > > "If the destination is a > directly connected network, or a router which connects to > the calculating router via a point-to-point interface, no > next hop IP address is required." > > Therefore, for a point-to-point link, the next hop consists only > of the outgoing interface. Does this answer your question or > am I missing something? > > Richard > > > Ah, now we are getting closer I think. Chapter 16.1.1 is rather big > describes > 3 cases(the third being the one that doesn't match case 1 or 2 ): > > If there is at least one intervening router in the current > shortest path between the destination and the root, the > destination simply inherits the set of next hops from the > parent. Otherwise, there are two cases. In the first case, > the parent vertex is the root (the calculating router > itself). > ..... > In the second case, the parent vertex is a network that > directly connects the calculating router to the destination > router. > > The text you quoted is from the first case and I have no problem with that > part and > it includes PtP links and both types of vertexes. > I have however only asked about the second case, I guess it got lost > somewhere. > > So looking only at the second case, does my theory make sense? > > > I think your point was that you don't see how point-to-point links fit > into the second case. I think the answer is that they don't, since > for point-to-point links, the parent vertex is not a network, but is > the calculating router. There is no transit network vertex associated > with a point-to-point link. Thus, a point-to-point link always falls > into the first case, not the second case. (This seems clear to me, > so I don't know why there was any confusion.) When I asked the question the first time I was not familiar with this part of the spec. Since then I have been reading up and now things are much clearer, thanks for the confirmation. Jocke _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From meneke@agora.pl Sun Jan 25 21:45:51 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A082C3A69E9 for ; Sun, 25 Jan 2009 21:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.204 X-Spam-Level: X-Spam-Status: No, score=-43.204 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] 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 pFvsgkK3vGMG for ; Sun, 25 Jan 2009 21:45:51 -0800 (PST) Received: from afjrotc.net (unknown [189.78.116.63]) by core3.amsl.com (Postfix) with SMTP id 75B173A6948 for ; Sun, 25 Jan 2009 21:45:47 -0800 (PST) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090126054549.75B173A6948@core3.amsl.com> Date: Sun, 25 Jan 2009 21:45:47 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.electricallow.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://electricallow.com/faq.php

Privacy Statement | Terms & Conditions | Contact

ALFAWORD Ltd.
Tower Bridge Business Complex. Unit 9, B630. 031 Clements Road. London. SE21 0DG

© 2006-2008 ALFAWORD, Ltd. All Rights Reserved

From nowmag@allstream.net Mon Jan 26 06:34:20 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DEB3A6BAC for ; Mon, 26 Jan 2009 06:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.391 X-Spam-Level: X-Spam-Status: No, score=-14.391 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 IYzSl+LQMNpq for ; Mon, 26 Jan 2009 06:34:17 -0800 (PST) Received: from host78-183-static.107-82-b.business.telecomitalia.it (host78-183-static.107-82-b.business.telecomitalia.it [82.107.183.78]) by core3.amsl.com (Postfix) with SMTP id E9B4A3A6BAB for ; Mon, 26 Jan 2009 06:34:14 -0800 (PST) To: Subject: Receipt for Your Payment From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090126143414.E9B4A3A6BAB@core3.amsl.com> Date: Mon, 26 Jan 2009 06:34:14 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.reflectionwant.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://reflectionwant.com/faq.php

Privacy Statement | Terms & Conditions | Contact

ALFAWORD Ltd.
Tower Bridge Business Complex. Unit 2, B471. 474 Clements Road. London. SE52 3DG

© 2006-2008 ALFAWORD, Ltd. All Rights Reserved

From moran@amcd.ie Mon Jan 26 08:34:18 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE28628C229 for ; Mon, 26 Jan 2009 08:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.758 X-Spam-Level: X-Spam-Status: No, score=-31.758 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] 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 FTdEh44PciSu for ; Mon, 26 Jan 2009 08:34:17 -0800 (PST) Received: from airpacific.co.jp (unknown [189.5.11.59]) by core3.amsl.com (Postfix) with SMTP id 52D013A6A79 for ; Mon, 26 Jan 2009 08:34:15 -0800 (PST) To: Subject: Smile your way through 2009 From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 090126-0, 26/01/2009), Outbound message X-Antivirus-Status: Clean Message-Id: <20090126163416.52D013A6A79@core3.amsl.com> Date: Mon, 26 Jan 2009 08:34:15 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello ospf-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L7851.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From kukcxoeytykih@ais-uk.org Mon Jan 26 11:39:06 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7C53A690E for ; Mon, 26 Jan 2009 11:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.458 X-Spam-Level: X-Spam-Status: No, score=-15.458 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 6dbj1usvnOQh for ; Mon, 26 Jan 2009 11:39:02 -0800 (PST) Received: from pushless-descent.volia.net (pushless-descent.volia.net [93.72.83.77]) by core3.amsl.com (Postfix) with SMTP id CA4F03A687C for ; Mon, 26 Jan 2009 11:38:58 -0800 (PST) To: Subject: Message from InterScan Messaging Security Suit From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090126193859.CA4F03A687C@core3.amsl.com> Date: Mon, 26 Jan 2009 11:38:58 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello ospf-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L9242.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From info@upgrade.com Mon Jan 26 11:43:39 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F5E3A69D3 for ; Mon, 26 Jan 2009 11:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUczANkLY9-h for ; Mon, 26 Jan 2009 11:43:39 -0800 (PST) Received: from webmail3.abac.com (webmail3.abac.com [216.55.191.213]) by core3.amsl.com (Postfix) with ESMTP id EA8A83A687C for ; Mon, 26 Jan 2009 11:43:38 -0800 (PST) Received: from webmail.bensonfamily.net (localhost.abac.com [127.0.0.1]) by webmail3.abac.com (8.14.2/8.14.2) with ESMTP id n0QJZHif060512; Mon, 26 Jan 2009 11:35:17 -0800 (PST) (envelope-from info@upgrade.com) Received: from 41.219.145.186 (SquirrelMail authenticated user jodi@bensonfamily.net) by webmail.bensonfamily.net with HTTP; Mon, 26 Jan 2009 16:35:22 -0300 (ART) Message-ID: <57530.41.219.145.186.1232998522.squirrel@webmail.bensonfamily.net> Date: Mon, 26 Jan 2009 16:35:22 -0300 (ART) Subject: Your Mailbox Exceeds Its Limit! From: "WebmailHelpDesk" Reply-To: upgrade_account555@live.com User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Dear Webmail User, The Helpdesk Program that periodically checks the size of your e-mailspace is sending you this information. The program runs weekly toensure your inbox does not grow too large, thus preventing you fromreceiving or sending new e-mail. As this message is being sent, youhave 18 megabytes (MB) or more stored in your inbox. To help us resetyour space in our database, please enter your current user name(_________________) password (_______________) You will receive a periodic alert if your inbox size is between 18 and20 MB. If your inbox size is 20 MB, a program on your Webmail willmove your oldest e-mails to a folder in your home directory to ensureyou can continue receiving incoming e-mail. You will be notified thishas taken place. If your inbox grows to 25 MB, you will be unable to receive new e-mailand it will be returned to sender. All this is programmed to ensureyour e-mail continues to function well. Thank you for your cooperation. Help Desk.Important: Email Account Verification Update ! ! ! From info@upgrade.com Mon Jan 26 11:44:07 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18ECE3A69D3 for ; Mon, 26 Jan 2009 11:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsbxwGSnb20f for ; Mon, 26 Jan 2009 11:44:07 -0800 (PST) Received: from webmail3.abac.com (webmail3.abac.com [216.55.191.213]) by core3.amsl.com (Postfix) with ESMTP id 8E0AE3A687C for ; Mon, 26 Jan 2009 11:44:06 -0800 (PST) Received: from webmail.bensonfamily.net (localhost.abac.com [127.0.0.1]) by webmail3.abac.com (8.14.2/8.14.2) with ESMTP id n0QJYQ50060361; Mon, 26 Jan 2009 11:34:26 -0800 (PST) (envelope-from info@upgrade.com) Received: from 41.219.145.186 (SquirrelMail authenticated user jodi@bensonfamily.net) by webmail.bensonfamily.net with HTTP; Mon, 26 Jan 2009 16:34:39 -0300 (ART) Message-ID: <57523.41.219.145.186.1232998479.squirrel@webmail.bensonfamily.net> Date: Mon, 26 Jan 2009 16:34:39 -0300 (ART) Subject: Your Mailbox Exceeds Its Limit! From: "WebmailHelpDesk" Reply-To: upgrade_account555@live.com User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Dear Webmail User, The Helpdesk Program that periodically checks the size of your e-mailspace is sending you this information. The program runs weekly toensure your inbox does not grow too large, thus preventing you fromreceiving or sending new e-mail. As this message is being sent, youhave 18 megabytes (MB) or more stored in your inbox. To help us resetyour space in our database, please enter your current user name(_________________) password (_______________) You will receive a periodic alert if your inbox size is between 18 and20 MB. If your inbox size is 20 MB, a program on your Webmail willmove your oldest e-mails to a folder in your home directory to ensureyou can continue receiving incoming e-mail. You will be notified thishas taken place. If your inbox grows to 25 MB, you will be unable to receive new e-mailand it will be returned to sender. All this is programmed to ensureyour e-mail continues to function well. Thank you for your cooperation. Help Desk.Important: Email Account Verification Update ! ! ! From info@upgrade.com Mon Jan 26 11:44:30 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE02B3A69D3 for ; Mon, 26 Jan 2009 11:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSfbO5o9PiRZ for ; Mon, 26 Jan 2009 11:44:30 -0800 (PST) Received: from webmail3.abac.com (webmail3.abac.com [216.55.191.213]) by core3.amsl.com (Postfix) with ESMTP id BAA6D3A687C for ; Mon, 26 Jan 2009 11:44:30 -0800 (PST) Received: from webmail.bensonfamily.net (localhost.abac.com [127.0.0.1]) by webmail3.abac.com (8.14.2/8.14.2) with ESMTP id n0QJZ0s1060457; Mon, 26 Jan 2009 11:35:01 -0800 (PST) (envelope-from info@upgrade.com) Received: from 41.219.145.186 (SquirrelMail authenticated user jodi@bensonfamily.net) by webmail.bensonfamily.net with HTTP; Mon, 26 Jan 2009 16:35:06 -0300 (ART) Message-ID: <57528.41.219.145.186.1232998506.squirrel@webmail.bensonfamily.net> Date: Mon, 26 Jan 2009 16:35:06 -0300 (ART) Subject: Your Mailbox Exceeds Its Limit! From: "WebmailHelpDesk" Reply-To: upgrade_account555@live.com User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Dear Webmail User, The Helpdesk Program that periodically checks the size of your e-mailspace is sending you this information. The program runs weekly toensure your inbox does not grow too large, thus preventing you fromreceiving or sending new e-mail. As this message is being sent, youhave 18 megabytes (MB) or more stored in your inbox. To help us resetyour space in our database, please enter your current user name(_________________) password (_______________) You will receive a periodic alert if your inbox size is between 18 and20 MB. If your inbox size is 20 MB, a program on your Webmail willmove your oldest e-mails to a folder in your home directory to ensureyou can continue receiving incoming e-mail. You will be notified thishas taken place. If your inbox grows to 25 MB, you will be unable to receive new e-mailand it will be returned to sender. All this is programmed to ensureyour e-mail continues to function well. Thank you for your cooperation. Help Desk.Important: Email Account Verification Update ! ! ! From mvbirgelenn@ambridge.nl Mon Jan 26 13:26:40 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E403A6814 for ; Mon, 26 Jan 2009 13:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.733 X-Spam-Level: * X-Spam-Status: No, score=1.733 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 wCgoKaFEy55E for ; Mon, 26 Jan 2009 13:26:36 -0800 (PST) Received: from 227-179-222-201.adsl.terra.cl (227-179-222-201.adsl.terra.cl [201.222.179.227]) by core3.amsl.com (Postfix) with SMTP id 772603A69F1 for ; Mon, 26 Jan 2009 13:26:34 -0800 (PST) To: Subject: Receipt for Your Payment From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090126212635.772603A69F1@core3.amsl.com> Date: Mon, 26 Jan 2009 13:26:34 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.meetgarden.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://meetgarden.com/faq.php

Privacy Statement | Terms & Conditions | Contact

ALFAWORD Ltd.
Tower Bridge Business Complex. Unit 4, B057. 963 Clements Road. London. SE21 0DG

© 2006-2008 ALFAWORD, Ltd. All Rights Reserved

From ospf-bounces@ietf.org Mon Jan 26 21:26:24 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 D53493A6A5B; Mon, 26 Jan 2009 21:26:24 -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 DE1163A6A5B for ; Mon, 26 Jan 2009 21:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[AWL=2.381, 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 Ra9Qq2NBCkW9 for ; Mon, 26 Jan 2009 21:26:23 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E45743A69FB for ; Mon, 26 Jan 2009 21:26:22 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KE40065I73FTL@szxga04-in.huawei.com> for ospf@ietf.org; Tue, 27 Jan 2009 13:26:03 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KE40076O73F9J@szxga04-in.huawei.com> for ospf@ietf.org; Tue, 27 Jan 2009 13:26:03 +0800 (CST) Received: from HTIPL108071671 ([10.18.23.113]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KE400FBQ73DIZ@szxml05-in.huawei.com> for ospf@ietf.org; Tue, 27 Jan 2009 13:26:03 +0800 (CST) Date: Tue, 27 Jan 2009 10:56:01 +0530 From: Abhijit Chaudhary To: Acee Lindem , Richard Ogier Message-id: <00a401c9803f$be74f240$7117120a@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 X-Priority: 3 X-MSMail-priority: Normal References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org > On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote: > >> I need to update the modification I suggested earlier. >> The problem is that in the DR election algorithm, an existing >> BDR is preferred over an Other for becoming a DR, regardless >> of router priority. Therefore, both the DR and the BDR must >> change their states to Other if they see an Other that has >> higher router priority. Hopefully, the following modification >> works and is backward compatible. > > I believe a router supporting the proposed "DR preemption" would simply > need to advertise itself as backup-DR to force a NeighborChange event on > in other OSPF routers on the network. ----> As Mitchell Erblich suggested, I too believe to trigger "DR preemption", the new router that the administrator wants to be DR, can announce itself as DR with higher priority than the existing DR of the network. This will trigger a NeighbourChange event that makes the new router as DR, while previous BDR (before the DR election) still exists to be the new BDR. I did not follow your suggestion to advertise the new router as backup-DR. As far as I understand, since a DR already exists for the network, announcing the new router as BDR will trigger neighbourchange event making the new router as BDR (not DR). Someone can please correct me if my understanding is wrong. Thanks, - Abhijit >> >> If a DR has a neighbor with a larger router priority, then it >> changes itself to an Other and runs the DR election algorithm. >> >> If a BDR has a non-DR neighbor with a larger router priority, then it >> changes itself to an Other and runs the DR election algorithm. >> Richard >> >> >> Abhijit Chaudhary wrote: >> >>> Hi, >>> According to RFC 2328, if a new router with higher priority is added to >>> the broadcast/NBMA network, it cannot become DR if DR and BDR already >>> exists for the network. This is done to avoid route- calculation, >>> advertisement of new LSA and temporary loss of data traffic. >>> But in some scenario, it may be desirable to make the new router as DR >>> because the new router has an upgraded software, has higher horse-power >>> (more memory, ...) and the existing DR is unable to take any more load >>> of the network. >>> In such scenario, is there any procedure to dynamically select the new >>> router as the DR without manually changing the configuration of the >>> existing DR and BDR? Does any other RFC define such a procedure? >>> >>> Thanks, >>> - Abhijit >>> . >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jan 26 21:57: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 2E82C3A68A9; Mon, 26 Jan 2009 21:57: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 1F9183A689A for ; Mon, 26 Jan 2009 21:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.04 X-Spam-Level: X-Spam-Status: No, score=0.04 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 v1IxAx-gucV2 for ; Mon, 26 Jan 2009 21:57:13 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 021053A6782 for ; Mon, 26 Jan 2009 21:57:13 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KE400C6R8IKSQ@szxga01-in.huawei.com> for ospf@ietf.org; Tue, 27 Jan 2009 13:56:45 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KE4009J08IKQ9@szxga01-in.huawei.com> for ospf@ietf.org; Tue, 27 Jan 2009 13:56:44 +0800 (CST) Received: from HTIPL108071671 ([10.18.23.113]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KE400F178IJIZ@szxml05-in.huawei.com> for ospf@ietf.org; Tue, 27 Jan 2009 13:56:44 +0800 (CST) Date: Tue, 27 Jan 2009 11:26:42 +0530 From: Abhijit Chaudhary To: Richard Ogier , Acee Lindem Message-id: <00ad01c98044$080bc3d0$7117120a@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 X-Priority: 3 X-MSMail-priority: Normal References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> <497A7611.7090300@earthlink.net> Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org > Acee Lindem wrote: > >> >> On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote: >> >>> I need to update the modification I suggested earlier. >>> The problem is that in the DR election algorithm, an existing >>> BDR is preferred over an Other for becoming a DR, regardless >>> of router priority. Therefore, both the DR and the BDR must >>> change their states to Other if they see an Other that has >>> higher router priority. Hopefully, the following modification >>> works and is backward compatible. >> >> >> I believe a router supporting the proposed "DR preemption" would simply >> need to advertise itself as backup-DR to force a NeighborChange event on >> in other OSPF routers on the network. > > > As you suggest, it would be better to have the DR change > to a BDR, rather than a DR Other, when possible. It may be > possible to do this if the router with larger router priority > is not a DR Other. The following rules might achieve this. > > 1. If the router is DR or BDR and has a DR Other neighbor with > a larger router priority, then it changes itself to DR Other. > > 2. Otherwise, if the router is DR and has a BDR neighbor with > a larger router priority, then it changes itself to BDR. > ----> Hi Richard, I actually meant DR pre-emption for a specific case (like software upgrade) when an administrator wants a router of his choice to become the DR. Following Step 1 & Step 2 that you mentioned above as part of the generic DR-election algorithm will actually trigger new DR/BDR to be selected everytime a new router with higher priority is added. As the RFC suggests, it may not be desirable to change the DR and BDR of the network often. Probably, the algorithm you mentioned can be kept as a separate DR-preemption algorithm, that gets triggered when a HELLO packet is received from a neighbour with a specific option bit set (DR-pre-emption bit). Thanks, - Abhijit > If step 2 is executed, then the neighboring BDR with larger > router priority will soon change its state to DR. > Hopefully, this will happen before the the next time the > router itself runs the DR election algorithm. If not, then > the router will change its state to DR Other temporarily, and then > back to BDR. To avoid this, I think the DR election algorithm > can be modified so that a BDR can remain a BDR if there is no > DR and only one BDR neighbor has a lexicographically larger > value of (RtrPri, RID). > > Obviously, some details need to be worked out. > > Richard > >> >> Thanks, >> Acee >> >> >>> >>> If a DR has a neighbor with a larger router priority, then it >>> changes itself to an Other and runs the DR election algorithm. >>> >>> If a BDR has a non-DR neighbor with a larger router priority, then it >>> changes itself to an Other and runs the DR election algorithm. >>> Richard >>> >>> >>> Abhijit Chaudhary wrote: >>> >>>> Hi, >>>> According to RFC 2328, if a new router with higher priority is added >>>> to the broadcast/NBMA network, it cannot become DR if DR and BDR >>>> already exists for the network. This is done to avoid route- >>>> calculation, advertisement of new LSA and temporary loss of data >>>> traffic. >>>> But in some scenario, it may be desirable to make the new router as DR >>>> because the new router has an upgraded software, has higher >>>> horse-power (more memory, ...) and the existing DR is unable to take >>>> any more load of the network. >>>> In such scenario, is there any procedure to dynamically select the new >>>> router as the DR without manually changing the configuration of the >>>> existing DR and BDR? Does any other RFC define such a procedure? >>>> >>>> Thanks, >>>> - Abhijit >>>> . >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jan 26 23:28:56 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 EDDCA3A69B3; Mon, 26 Jan 2009 23:28:55 -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 1EAE028C0D6 for ; Mon, 26 Jan 2009 23:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 2zn9gs781D6U for ; Mon, 26 Jan 2009 23:28:54 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id B1EAD3A689A for ; Mon, 26 Jan 2009 23:28:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSX63k5mg6IMcCgnoKFTuSXqBv0M5TJ8H@postini.com; Mon, 26 Jan 2009 23:28:36 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.336.0; Mon, 26 Jan 2009 23:25:29 -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, 26 Jan 2009 23:25:29 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jan 2009 23:25:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 23:25:28 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0R7PRM72314; Mon, 26 Jan 2009 23:25:27 -0800 (PST) (envelope-from dkatz@juniper.net) From: Dave Katz To: Abhijit Chaudhary In-Reply-To: <00ad01c98044$080bc3d0$7117120a@china.huawei.com> X-Priority: 3 References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> <497A7611.7090300@earthlink.net> <00ad01c98044$080bc3d0$7117120a@china.huawei.com> Message-ID: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 27 Jan 2009 00:25:26 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 27 Jan 2009 07:25:28.0406 (UTC) FILETIME=[6DC3D760:01C98050] Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 There's some confusion here. Normally, simply raising the priority on a box will *not* make it DR. This is to avoid a new router showing up from seizing DR-ship to avoid a new DR election. In this scenario, the new router will not be declaring *itself* to be DR, so the DR election algorithm will ignore it unless there is no other DR. If, on the other hand, you wanted to make a router become DR preemptively, all it needs is to have the highest priority and to claim (in its Hello packets) that it is already the DR; this is the fait accompli that will make it become DR. This is a fine case of cheating the spec in a way that is useful and interoperable, *if you're careful.* What would be a rather bad thing, however, is to claim that you're DR when you're not, and not going to be. If you're trying to preempt like this, but the "real" DR has a higher priority (or the same priority but a higher router ID) then you're going to mess things up. So any implementation that tries to pull this off needs a fail-safe mechanism of some sort to keep from totally screwing things up. This sort of shenanigans runs the risk of tweaking bugs in other peoples' implementations, and while you might have the moral high ground in saying that it has to work unless the other guy is broken, this gains you little traction with customers, particularly when the other guy's broken implementation happens to have the highest market penetration (he says, speaking from experience.) --Dave On Jan 26, 2009, at 10:56 PM, Abhijit Chaudhary wrote: > >> Acee Lindem wrote: >> >>> >>> On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote: >>> >>>> I need to update the modification I suggested earlier. >>>> The problem is that in the DR election algorithm, an existing >>>> BDR is preferred over an Other for becoming a DR, regardless >>>> of router priority. Therefore, both the DR and the BDR must >>>> change their states to Other if they see an Other that has >>>> higher router priority. Hopefully, the following modification >>>> works and is backward compatible. >>> >>> >>> I believe a router supporting the proposed "DR preemption" would >>> simply need to advertise itself as backup-DR to force a >>> NeighborChange event on in other OSPF routers on the network. >> >> >> As you suggest, it would be better to have the DR change >> to a BDR, rather than a DR Other, when possible. It may be >> possible to do this if the router with larger router priority >> is not a DR Other. The following rules might achieve this. >> >> 1. If the router is DR or BDR and has a DR Other neighbor with >> a larger router priority, then it changes itself to DR Other. >> >> 2. Otherwise, if the router is DR and has a BDR neighbor with >> a larger router priority, then it changes itself to BDR. >> > ----> > Hi Richard, > I actually meant DR pre-emption for a specific case (like software > upgrade) when an administrator wants a router of his choice to > become the DR. > Following Step 1 & Step 2 that you mentioned above as part of the > generic DR-election algorithm will actually trigger new DR/BDR to be > selected everytime a new router with higher priority is added. As > the RFC suggests, it may not be desirable to change the DR and BDR > of the network often. > Probably, the algorithm you mentioned can be kept as a separate DR- > preemption algorithm, that gets triggered when a HELLO packet is > received from a neighbour with a specific option bit set (DR-pre- > emption bit). > Thanks, > - Abhijit > >> If step 2 is executed, then the neighboring BDR with larger >> router priority will soon change its state to DR. >> Hopefully, this will happen before the the next time the >> router itself runs the DR election algorithm. If not, then >> the router will change its state to DR Other temporarily, and then >> back to BDR. To avoid this, I think the DR election algorithm >> can be modified so that a BDR can remain a BDR if there is no >> DR and only one BDR neighbor has a lexicographically larger >> value of (RtrPri, RID). >> >> Obviously, some details need to be worked out. >> >> Richard >> >>> >>> Thanks, >>> Acee >>> >>> >>>> >>>> If a DR has a neighbor with a larger router priority, then it >>>> changes itself to an Other and runs the DR election algorithm. >>>> >>>> If a BDR has a non-DR neighbor with a larger router priority, >>>> then it >>>> changes itself to an Other and runs the DR election algorithm. >>>> Richard >>>> >>>> >>>> Abhijit Chaudhary wrote: >>>> >>>>> Hi, >>>>> According to RFC 2328, if a new router with higher priority is >>>>> added to the broadcast/NBMA network, it cannot become DR if DR >>>>> and BDR already exists for the network. This is done to avoid >>>>> route- calculation, advertisement of new LSA and temporary loss >>>>> of data traffic. >>>>> But in some scenario, it may be desirable to make the new >>>>> router as DR because the new router has an upgraded software, >>>>> has higher horse-power (more memory, ...) and the existing DR is >>>>> unable to take any more load of the network. >>>>> In such scenario, is there any procedure to dynamically select >>>>> the new router as the DR without manually changing the >>>>> configuration of the existing DR and BDR? Does any other RFC >>>>> define such a procedure? >>>>> >>>>> Thanks, >>>>> - Abhijit >>>>> . >>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> >>> > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 27 00:08:32 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 92B353A6A87; Tue, 27 Jan 2009 00:08:32 -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 F323428C169 for ; Tue, 27 Jan 2009 00:08:30 -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 0NhEkZiywRyW for ; Tue, 27 Jan 2009 00:08:29 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 980423A6A43 for ; Tue, 27 Jan 2009 00:08:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NzJrqOcvCxum+2qJ53St8zf8Mc87farieGl59Ay3q3X2ZnmgaYvZtszbrblgJblb; h=Received:From:To:In-Reply-To:Subject:X-Priority:References:Message-Id:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Cc:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.234.127.54] (helo=[10.0.1.5]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1LRizO-0002lQ-CD; Tue, 27 Jan 2009 03:08:06 -0500 From: Mitchell Erblich To: Dave Katz In-Reply-To: X-Priority: 3 References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> <497A7611.7090300@earthlink.net> <00ad01c98044$080bc3d0$7117120a@china.huawei.com> Message-Id: <458D4F66-8597-4C10-BB5E-71FA4F043776@earthlink.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 27 Jan 2009 00:08:04 -0800 X-Mailer: Apple Mail (2.930.3) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec795373b3b7a1a845309a24c91aea8a3148350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.234.127.54 Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Dave Katz, Et Al I partially agree.. ... DR re-election when a area JOINING results in two DRs is a required supported functionality via RFC AND SHOULD NOT tweak bugs.. Identifing the RIGHT mechanics matching the arch and having a Fail- safe implementation that achieves without side-effects the desired result is almost a bit of an art, IMO. And ONE should NOT believe that all the expected pitfalls have been discussed in this thread. Mitchell Erblich ========================= On Jan 26, 2009, at 11:25 PM, Dave Katz wrote: > There's some confusion here. > > Normally, simply raising the priority on a box will *not* make it > DR. This is to avoid a new router showing up from seizing DR-ship > to avoid a new DR election. In this scenario, the new router will > not be declaring *itself* to be DR, so the DR election algorithm > will ignore it unless there is no other DR. > > If, on the other hand, you wanted to make a router become DR > preemptively, all it needs is to have the highest priority and to > claim (in its Hello packets) that it is already the DR; this is the > fait accompli that will make it become DR. This is a fine case of > cheating the spec in a way that is useful and interoperable, *if > you're careful.* What would be a rather bad thing, however, is to > claim that you're DR when you're not, and not going to be. If > you're trying to preempt like this, but the "real" DR has a higher > priority (or the same priority but a higher router ID) then you're > going to mess things up. So any implementation that tries to pull > this off needs a fail-safe mechanism of some sort to keep from > totally screwing things up. > > This sort of shenanigans runs the risk of tweaking bugs in other > peoples' implementations, and while you might have the moral high > ground in saying that it has to work unless the other guy is broken, > this gains you little traction with customers, particularly when the > other guy's broken implementation happens to have the highest market > penetration (he says, speaking from experience.) > > --Dave > > On Jan 26, 2009, at 10:56 PM, Abhijit Chaudhary wrote: > >> >>> Acee Lindem wrote: >>> >>>> >>>> On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote: >>>> >>>>> I need to update the modification I suggested earlier. >>>>> The problem is that in the DR election algorithm, an existing >>>>> BDR is preferred over an Other for becoming a DR, regardless >>>>> of router priority. Therefore, both the DR and the BDR must >>>>> change their states to Other if they see an Other that has >>>>> higher router priority. Hopefully, the following modification >>>>> works and is backward compatible. >>>> >>>> >>>> I believe a router supporting the proposed "DR preemption" would >>>> simply need to advertise itself as backup-DR to force a >>>> NeighborChange event on in other OSPF routers on the network. >>> >>> >>> As you suggest, it would be better to have the DR change >>> to a BDR, rather than a DR Other, when possible. It may be >>> possible to do this if the router with larger router priority >>> is not a DR Other. The following rules might achieve this. >>> >>> 1. If the router is DR or BDR and has a DR Other neighbor with >>> a larger router priority, then it changes itself to DR Other. >>> >>> 2. Otherwise, if the router is DR and has a BDR neighbor with >>> a larger router priority, then it changes itself to BDR. >>> >> ----> >> Hi Richard, >> I actually meant DR pre-emption for a specific case (like software >> upgrade) when an administrator wants a router of his choice to >> become the DR. >> Following Step 1 & Step 2 that you mentioned above as part of the >> generic DR-election algorithm will actually trigger new DR/BDR to >> be selected everytime a new router with higher priority is added. >> As the RFC suggests, it may not be desirable to change the DR and >> BDR of the network often. >> Probably, the algorithm you mentioned can be kept as a separate DR- >> preemption algorithm, that gets triggered when a HELLO packet is >> received from a neighbour with a specific option bit set (DR-pre- >> emption bit). >> Thanks, >> - Abhijit >> >>> If step 2 is executed, then the neighboring BDR with larger >>> router priority will soon change its state to DR. >>> Hopefully, this will happen before the the next time the >>> router itself runs the DR election algorithm. If not, then >>> the router will change its state to DR Other temporarily, and then >>> back to BDR. To avoid this, I think the DR election algorithm >>> can be modified so that a BDR can remain a BDR if there is no >>> DR and only one BDR neighbor has a lexicographically larger >>> value of (RtrPri, RID). >>> >>> Obviously, some details need to be worked out. >>> >>> Richard >>> >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>>> >>>>> If a DR has a neighbor with a larger router priority, then it >>>>> changes itself to an Other and runs the DR election algorithm. >>>>> >>>>> If a BDR has a non-DR neighbor with a larger router priority, >>>>> then it >>>>> changes itself to an Other and runs the DR election algorithm. >>>>> Richard >>>>> >>>>> >>>>> Abhijit Chaudhary wrote: >>>>> >>>>>> Hi, >>>>>> According to RFC 2328, if a new router with higher priority is >>>>>> added to the broadcast/NBMA network, it cannot become DR if DR >>>>>> and BDR already exists for the network. This is done to avoid >>>>>> route- calculation, advertisement of new LSA and temporary loss >>>>>> of data traffic. >>>>>> But in some scenario, it may be desirable to make the new >>>>>> router as DR because the new router has an upgraded software, >>>>>> has higher horse-power (more memory, ...) and the existing DR >>>>>> is unable to take any more load of the network. >>>>>> In such scenario, is there any procedure to dynamically select >>>>>> the new router as the DR without manually changing the >>>>>> configuration of the existing DR and BDR? Does any other RFC >>>>>> define such a procedure? >>>>>> >>>>>> Thanks, >>>>>> - Abhijit >>>>>> . >>>>>> >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >>>> >>>> >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jan 27 00:20:35 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 C7C9A3A6B38; Tue, 27 Jan 2009 00:20:35 -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 40B4E3A6B38 for ; Tue, 27 Jan 2009 00:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 qmIzrxdSTcjA for ; Tue, 27 Jan 2009 00:20:33 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 6FF4B3A6B16 for ; Tue, 27 Jan 2009 00:20:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSX7DvGc1uP7nFrot2yC8XJAxwaQcTzuz@postini.com; Tue, 27 Jan 2009 00:20:16 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.336.0; Tue, 27 Jan 2009 00:17:51 -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); Tue, 27 Jan 2009 00:17:50 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 00:17:50 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 00:17:50 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0R8HnM96590; Tue, 27 Jan 2009 00:17:49 -0800 (PST) (envelope-from dkatz@juniper.net) From: Dave Katz To: Mitchell Erblich In-Reply-To: <458D4F66-8597-4C10-BB5E-71FA4F043776@earthlink.net> X-Priority: 3 References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> <497A7611.7090300@earthlink.net> <00ad01c98044$080bc3d0$7117120a@china.huawei.com> <458D4F66-8597-4C10-BB5E-71FA4F043776@earthlink.net> Message-ID: <2F1120C5-0800-4434-B22D-EAF340FC284E@juniper.net> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 27 Jan 2009 01:17:49 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 27 Jan 2009 08:17:50.0174 (UTC) FILETIME=[BE6797E0:01C98057] Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On Jan 27, 2009, at 1:08 AM, Mitchell Erblich wrote: > Dave Katz, Et Al > > I partially agree.. > > ... DR re-election when a area JOINING results in two DRs is a > required > supported functionality via RFC AND SHOULD NOT tweak bugs.. "SHOULD NOT" is the key. And refreshing your LSAs every 50 minutes instead of every 30 minutes SHOULD NOT cause problems. But it did. In three different implementations from multiple companies. I couldn't figure out for the life of me how it was even possible, and finally begged someone to explain it. True evil genius. > > > Identifing the RIGHT mechanics matching the arch and having a Fail- > safe implementation > that achieves without side-effects the desired result is almost a > bit of an art, IMO. It requires knowing the *whys* of the protocol mechanisms, which are not always obvious and are seldom documented. And a really healthy sense of paranoia. > > > And ONE should NOT believe that all the expected pitfalls have > been discussed in this > thread. Amen. --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From jonas@almroth.name Tue Jan 27 06:51:31 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69623A67B5 for ; Tue, 27 Jan 2009 06:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16 X-Spam-Level: X-Spam-Status: No, score=-16 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 MQwRxpmEW9Cl for ; Tue, 27 Jan 2009 06:51:26 -0800 (PST) Received: from alexiskrsk.kraslan.ru (alexiskrsk.kraslan.ru [93.90.249.108]) by core3.amsl.com (Postfix) with SMTP id 818F33A6B3E for ; Tue, 27 Jan 2009 06:51:04 -0800 (PST) To: Subject: New products everyday at our chemists. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127145105.818F33A6B3E@core3.amsl.com> Date: Tue, 27 Jan 2009 06:51:04 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello ospf-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L7605.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From ospf-bounces@ietf.org Tue Jan 27 09:50:12 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 BD7DB28C1A3; Tue, 27 Jan 2009 09:50:12 -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 DC60628C1A8 for ; Tue, 27 Jan 2009 09:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 JtjebxrAfm2B for ; Tue, 27 Jan 2009 09:50:10 -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 9EF1128C19F for ; Tue, 27 Jan 2009 09:50:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=swG3ew7IguhrdrbOOvnn7z6mwcOq0LsRB/sx0aLRm6OHGYtz/y6ZtxOSH+dqSAux; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.223.245] by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LRs4M-0001Z4-K7; Tue, 27 Jan 2009 12:49:52 -0500 Message-ID: <497F49A8.2090404@earthlink.net> Date: Tue, 27 Jan 2009 09:51:36 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abhijit Chaudhary References: <14842AE7A5944227B77EE637E169CA29@homexpc> <555BD17F-DBBA-4164-B481-0C180D324B61@redback.com> <002801c97d39$fca88440$7117120a@china.huawei.com> <4979F5B3.60807@earthlink.net> <497A7611.7090300@earthlink.net> <00ad01c98044$080bc3d0$7117120a@china.huawei.com> In-Reply-To: <00ad01c98044$080bc3d0$7117120a@china.huawei.com> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4786895b6c114b710cdcf996b4bfd435bda839848bf58fae6a0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.223.245 Cc: ospf@ietf.org Subject: Re: [OSPF] Regarding DR Selection X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Abhijit Chaudhary wrote: > >> Acee Lindem wrote: >> >>> >>> On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote: >>> >>>> I need to update the modification I suggested earlier. >>>> The problem is that in the DR election algorithm, an existing >>>> BDR is preferred over an Other for becoming a DR, regardless >>>> of router priority. Therefore, both the DR and the BDR must >>>> change their states to Other if they see an Other that has >>>> higher router priority. Hopefully, the following modification >>>> works and is backward compatible. >>> >>> >>> >>> I believe a router supporting the proposed "DR preemption" would >>> simply need to advertise itself as backup-DR to force a >>> NeighborChange event on in other OSPF routers on the network. >> >> >> >> As you suggest, it would be better to have the DR change >> to a BDR, rather than a DR Other, when possible. It may be >> possible to do this if the router with larger router priority >> is not a DR Other. The following rules might achieve this. >> >> 1. If the router is DR or BDR and has a DR Other neighbor with >> a larger router priority, then it changes itself to DR Other. >> >> 2. Otherwise, if the router is DR and has a BDR neighbor with >> a larger router priority, then it changes itself to BDR. >> > ----> > Hi Richard, > I actually meant DR pre-emption for a specific case (like software > upgrade) when an administrator wants a router of his choice to become > the DR. > Following Step 1 & Step 2 that you mentioned above as part of the > generic DR-election algorithm will actually trigger new DR/BDR to be > selected everytime a new router with higher priority is added. As the > RFC suggests, it may not be desirable to change the DR and BDR of the > network often. Right. But as you pointed out, some implementors might prefer that the DR should always be a router with the highest router priority, so the steps I suggested would provide this feature in a backward compatible way, if they are implemented on all routers attached to a given broadcast network. I realize this is different from your objective. > Probably, the algorithm you mentioned can be kept as a separate > DR-preemption algorithm, that gets triggered when a HELLO packet is > received from a neighbour with a specific option bit set > (DR-pre-emption bit). Right. But you don't really need a new option bit, since it is backward compatible. A router that uses the new feature will only downgrade its DR status if there is a neighbor with higher router priority, and there is no need for that neighbor to select the DR-preemption option. Richard > Thanks, > - Abhijit > >> If step 2 is executed, then the neighboring BDR with larger >> router priority will soon change its state to DR. >> Hopefully, this will happen before the the next time the >> router itself runs the DR election algorithm. If not, then >> the router will change its state to DR Other temporarily, and then >> back to BDR. To avoid this, I think the DR election algorithm >> can be modified so that a BDR can remain a BDR if there is no >> DR and only one BDR neighbor has a lexicographically larger >> value of (RtrPri, RID). >> >> Obviously, some details need to be worked out. >> >> Richard >> >>> >>> Thanks, >>> Acee >>> >>> >>>> >>>> If a DR has a neighbor with a larger router priority, then it >>>> changes itself to an Other and runs the DR election algorithm. >>>> >>>> If a BDR has a non-DR neighbor with a larger router priority, then it >>>> changes itself to an Other and runs the DR election algorithm. >>>> Richard >>>> >>>> >>>> Abhijit Chaudhary wrote: >>>> >>>>> Hi, >>>>> According to RFC 2328, if a new router with higher priority is >>>>> added to the broadcast/NBMA network, it cannot become DR if DR >>>>> and BDR already exists for the network. This is done to avoid >>>>> route- calculation, advertisement of new LSA and temporary loss of >>>>> data traffic. >>>>> But in some scenario, it may be desirable to make the new router >>>>> as DR because the new router has an upgraded software, has higher >>>>> horse-power (more memory, ...) and the existing DR is unable to >>>>> take any more load of the network. >>>>> In such scenario, is there any procedure to dynamically select >>>>> the new router as the DR without manually changing the >>>>> configuration of the existing DR and BDR? Does any other RFC >>>>> define such a procedure? >>>>> >>>>> Thanks, >>>>> - Abhijit >>>>> . >>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> >>> >>> >> > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From matthew@absoluteestates.com Wed Jan 28 16:42:55 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581AE3A68EB for ; Wed, 28 Jan 2009 16:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.084 X-Spam-Level: X-Spam-Status: No, score=-43.084 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 tj0l0DSrMwvI for ; Wed, 28 Jan 2009 16:42:54 -0800 (PST) Received: from amgen.com (unknown [189.63.56.95]) by core3.amsl.com (Postfix) with SMTP id D61DA3A687F for ; Wed, 28 Jan 2009 16:42:51 -0800 (PST) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090129004252.D61DA3A687F@core3.amsl.com> Date: Wed, 28 Jan 2009 16:42:51 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.independenceisland.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://independenceisland.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B341. 246 Clements Road. London. SE82 1DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From majordomo@amkya.com Wed Jan 28 20:55:33 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D8D3A6932 for ; Wed, 28 Jan 2009 20:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.287 X-Spam-Level: X-Spam-Status: No, score=-22.287 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 Dv05d3tRrcXu for ; Wed, 28 Jan 2009 20:55:32 -0800 (PST) Received: from akfelix.cz (unknown [79.107.73.115]) by core3.amsl.com (Postfix) with SMTP id 8D2573A68DD for ; Wed, 28 Jan 2009 20:55:30 -0800 (PST) To: Subject: Welcome to eBay! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090129045531.8D2573A68DD@core3.amsl.com> Date: Wed, 28 Jan 2009 20:55:30 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.valleyhot.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://valleyhot.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B208. 601 Clements Road. London. SE09 7DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From krissada_t2000@absincorp.com Thu Jan 29 06:50:56 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7C33A69B4 for ; Thu, 29 Jan 2009 06:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.732 X-Spam-Level: X-Spam-Status: No, score=-22.732 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] 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 U7ijxogQkVlE for ; Thu, 29 Jan 2009 06:50:56 -0800 (PST) Received: from ajman.ac.ae (unknown [189.32.203.71]) by core3.amsl.com (Postfix) with SMTP id 1A6953A6858 for ; Thu, 29 Jan 2009 06:50:53 -0800 (PST) To: Subject: PayPal - Email Handling Opinion Needed From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090129145054.1A6953A6858@core3.amsl.com> Date: Thu, 29 Jan 2009 06:50:53 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.independenceisland.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://independenceisland.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B638. 446 Clements Road. London. SE77 6DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From jbarrile@aguasbonaerenses.com.ar Thu Jan 29 11:49:39 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5963A68BC for ; Thu, 29 Jan 2009 11:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.293 X-Spam-Level: X-Spam-Status: No, score=-42.293 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MANGLED_BEST=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 5c8-ukKq4Eq4 for ; Thu, 29 Jan 2009 11:49:38 -0800 (PST) Received: from alexmann.com (unknown [189.58.163.228]) by core3.amsl.com (Postfix) with SMTP id 27D3E3A6832 for ; Thu, 29 Jan 2009 11:49:36 -0800 (PST) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090129194937.27D3E3A6832@core3.amsl.com> Date: Thu, 29 Jan 2009 11:49:36 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.awardzeal.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://awardzeal.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 4, B357. 722 Clements Road. London. SE68 9DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From mauro@alie.br Fri Jan 30 09:20:53 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B6728C27C for ; Fri, 30 Jan 2009 09:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.677 X-Spam-Level: X-Spam-Status: No, score=-9.677 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, GB_I_LETTER=-2, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 x60c8lOyKSg3 for ; Fri, 30 Jan 2009 09:20:52 -0800 (PST) Received: from host177-34-dynamic.47-79-r.retail.telecomitalia.it (host177-34-dynamic.47-79-r.retail.telecomitalia.it [79.47.34.177]) by core3.amsl.com (Postfix) with SMTP id 1E7743A6965 for ; Fri, 30 Jan 2009 09:20:50 -0800 (PST) To: Subject: Customer Receipt/Purchase Confirmation From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090130172051.1E7743A6965@core3.amsl.com> Date: Fri, 30 Jan 2009 09:20:50 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.clearzest.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://clearzest.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 0, B745. 523 Clements Road. London. SE86 3DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From nbrboulder@alfa.org Fri Jan 30 11:22:52 2009 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149EC3A69FC for ; Fri, 30 Jan 2009 11:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.609 X-Spam-Level: X-Spam-Status: No, score=-9.609 tagged_above=-999 required=5 tests=[AWL=3.093, BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 4GzehfCecV0M for ; Fri, 30 Jan 2009 11:22:50 -0800 (PST) Received: from bql240.neoplus.adsl.tpnet.pl (bql240.neoplus.adsl.tpnet.pl [83.29.79.240]) by core3.amsl.com (Postfix) with SMTP id 359723A69ED for ; Fri, 30 Jan 2009 11:22:25 -0800 (PST) To: Subject: Sales Order from walmart.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090130192227.359723A69ED@core3.amsl.com> Date: Fri, 30 Jan 2009 11:22:25 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.meeksure.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://meeksure.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B589. 130 Clements Road. London. SE21 5DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved