From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 01 18:50:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEb56-0003TE-4n for ospf-archive@LISTS.IETF.ORG; Wed, 01 Mar 2006 18:50:08 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEb54-0004wb-TL for ospf-archive@LISTS.IETF.ORG; Wed, 01 Mar 2006 18:50:08 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.0003AC95@wildebeest.ease.lsoft.com>; Wed, 1 Mar 2006 18:50:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100751187 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 1 Mar 2006 18:50:04 -0500 Received: from 209.173.53.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 1 Mar 2006 18:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k21No2BX023123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEb50-0000Ly-6B; Wed, 01 Mar 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Wed, 1 Mar 2006 18:50:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@IETF.ORG Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-08.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-08.txt Pages : 15 Date : 2006-3-1 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-auth-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-1164411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-1164411.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 01 21:52:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEdvz-0000kA-RS for ospf-archive@LISTS.IETF.ORG; Wed, 01 Mar 2006 21:52:55 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEdvz-0005Ln-HO for ospf-archive@LISTS.IETF.ORG; Wed, 01 Mar 2006 21:52:55 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.0003AFB9@wildebeest.ease.lsoft.com>; Wed, 1 Mar 2006 21:52:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100779443 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 1 Mar 2006 21:52:53 -0500 Received: from 12.129.211.51 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 1 Mar 2006 21:52:53 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVH00E5IBIDOZ@usaga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 01 Mar 2006 18:42:14 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVH007PBC8X0F@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 02 Mar 2006 10:58:09 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVH00BMTC8RE1@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 02 Mar 2006 10:58:09 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVH00ES9C8N98@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 02 Mar 2006 10:57:59 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> <43F9DD10.8040305@cisco.com> <001601c636e4$5ea03980$610c6f0a@china.huawei.com> <43FCDA9B.9050307@cisco.com> <000701c63928$9908e590$610c6f0a@china.huawei.com> <43FF13BB.9030903@cisco.com> <000801c63c19$3121b760$610c6f0a@china.huawei.com> <44044364.30701@cisco.com> Message-ID: <001701c63da3$58fd0ba0$610c6f0a@china.huawei.com> Date: Thu, 2 Mar 2006 10:45:20 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Hi, Acee Yes, you are correct. There are two cases as following when DR election. Case 1: 0----------------------------------------------------------------------------> Time init->2-way ----------------------- dr election | | Sending Immediate Hello Case 2: 0----------------------------------------------------------------------------> Time init->2-way ----------------------- dr election | | | Sending Immediate Hello For case 2, the DR election result is same to RFC2328. For case 1,the DR election result is different to RFC2328. In order to keep consistent to RFC2328, we may adopt case2 in immediate hello. Thanks, Zengjie ----- Original Message ----- From: "Acee Lindem" To: Sent: Tuesday, February 28, 2006 8:34 PM Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt > Zengjie Kou wrote: > >>Hi, Acee >> On p2p networks, there is no distinction between first coming or coming back up. The immediate hello is efficient in discover neighbors and convergence. >> On broadcast networks, when an interface first coming, DR election need to wait wait-time. However, when an interface coming back up, DR election need not to wait wait-time(if BDR exists or the down interface is not DR). Here, only HelloInterval or BackupSeen is needed to discover neighbor or convergence. Immediate hello avoids the HelloInterval or backupSeen on the case. >> >> > Hi Zengjie, > > I think you're saying the hello when the DR/BDR interface state changes > is solely for > the case when the BDR's interface flaps. Correct? > > BDR Interface goes down > Ex-BDR Interface comes back up > Ex-BDR send initial hello ----------------------------> Other > Routers on LAN > Ex-BDR goes to 2-way <---------------------------- Other Routers > Immediate reply > > New DR/BDR election > Triggers election on Ex-BDR <---------------------- New DR/BDR > send hello > > Why not just process the neighbor change event before sending the > immediate reply? > In other words, perform the new DR/BDR election before the immediate > reply hello? > > Thanks, > Acee > >>Thanks, >>Zengjie >> >> >>----- Original Message ----- >>From: "Acee Lindem" >>To: >>Sent: Friday, February 24, 2006 10:10 PM >>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >> >> >> >> >>>Zengjie Kou wrote: >>> >>> >>> >>>>Hi, Acee >>>> The empty hello mechanism that you refered is adopted by most OSPF implementations indeed when an interface first comes up. >>>>I agree this. However, when an normal interface whose state is up goes down then up, immediate hello is effective by avoiding >>>>helloInterval or backupSeen. >>>> >>>> >>>> >>>> >>>Hi Zengjie, >>> >>>I don't think there should be a distinction between first coming or >>>coming back up. >>> >>>Thanks, >>>Acee >>> >>> >>> >>>>Thanks, >>>>Zengjie >>>> >>>>----- Original Message ----- >>>>From: "Acee Lindem" >>>>To: >>>>Sent: Thursday, February 23, 2006 5:41 AM >>>>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Zengjie Kou wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi, Acee, >>>>>> You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Hi Zengjie, >>>>> >>>>>Speaking strictly in terms of state machines, it seems the interface >>>>>would lose it's DR/BDR state >>>>>when it goes down (and cannot send a hello). Wouldn't this scenario be >>>>>better handled >>>>>by the empty hello many OSPF implementations send when an interface >>>>>first comes up? >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Thanks, >>>>>>Zengjie >>>>>> >>>>>>----- Original Message ----- >>>>>>From: "Acee Lindem" >>>>>>To: >>>>>>Sent: Monday, February 20, 2006 11:15 PM >>>>>>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi Zengjie, >>>>>>> >>>>>>>Zengjie Kou wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi,Acee, >>>>>>>> If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>This is only when the DR/BDR knows that it is going down or the case >>>>>>>where the router >>>>>>>priority is set to 0. >>>>>>> >>>>>>>For a router becoming DR/BDR, all the routers should elect the same DR/BDR >>>>>>>so I don't see how it helps. >>>>>>> >>>>>>>Thanks, >>>>>>>Acee >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. >>>>>>>>Namely, improving convergence. >>>>>>>> >>>>>>>>Thanks a lot, >>>>>>>>Zengjie >>>>>>>> >>>>>>>>----- Original Message ----- >>>>>>>>From: "Acee Lindem" >>>>>>>>To: >>>>>>>>Sent: Saturday, February 18, 2006 5:17 AM >>>>>>>>Subject: draft-kou-ospf-immediately-replying-hello-00.txt >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi Zengjie, >>>>>>>>> >>>>>>>>>Under what situations does having the router who changed to/from >>>>>>>>>DR/BDR improve convergence (section 6.2)? Since DR/BDR election >>>>>>>>>is a distributed algorithm dependent on the calculating routers state, it >>>>>>>>>seems this won't help in all that many cases. >>>>>>>>> >>>>>>>>>Thanks, >>>>>>>>>Acee >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 02 15:50:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEukO-0006Dl-VT for ospf-archive@LISTS.IETF.ORG; Thu, 02 Mar 2006 15:50:05 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEukO-0006rp-M1 for ospf-archive@LISTS.IETF.ORG; Thu, 02 Mar 2006 15:50:04 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.0003BC86@wildebeest.ease.lsoft.com>; Thu, 2 Mar 2006 15:50:04 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:Content-Type:Mime-Version:Message-ID:Date:Reply-To:Sender:From:Subject:Comments:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=XScDuqiHW9K6QlCbusL49AobfDdqqEqsO6gsi56qCLHkEBLp0ZuuRQoUzFGLgyJFtN2fqGBasLrmewv78rG0GhNbjeqb8Sj8zD2dtFT+C6zwDadOTIj1woaJXLIqO5ac; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 100848736 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 2 Mar 2006 15:50:03 -0500 Received: from 209.173.53.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 2 Mar 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko3BX003479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukM-0003TM-Ve; Thu, 02 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Thu, 2 Mar 2006 15:50:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@IETF.ORG Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-08.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF for IPv6 Author(s) : D. Ferguson, et al. Filename : draft-ietf-ospf-ospfv3-update-08.txt Pages : 98 Date : 2006-3-2 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload. Even with larger IPv6 packet, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-update-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2145935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-update-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2145935.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 02 16:09:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEv2s-0003hq-W8 for ospf-archive@LISTS.IETF.ORG; Thu, 02 Mar 2006 16:09:11 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEv2s-0002Rh-LY for ospf-archive@LISTS.IETF.ORG; Thu, 02 Mar 2006 16:09:10 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0003BB64@wildebeest.ease.lsoft.com>; Thu, 2 Mar 2006 16:09:10 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=TpHNKJyjZLuQcNvvXK6jGgEsThieU7BWVxC0uubIF9KLSH0PQvxik+TY+voCsL7ZuD12UaQ1yO7oPKLRaIEluIlm6LoX+gO7ur+ThM032iokTLsh5CkCqLYqWk2sSP74; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 100850093 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 2 Mar 2006 16:09:09 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 2 Mar 2006 16:08:40 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 02 Mar 2006 13:08:39 -0800 X-IronPort-AV: i="4.02,160,1139212800"; d="scan'208"; a="311349014:sNHT33203348" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k22L8YH3002358 for ; Thu, 2 Mar 2006 13:08:39 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 16:08:36 -0500 Received: from [10.82.209.35] ([10.82.209.35]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 16:08:36 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2006 21:08:36.0203 (UTC) FILETIME=[787D1BB0:01C63E3D] Message-ID: <44075ED3.2030402@cisco.com> Date: Thu, 2 Mar 2006 16:08:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-update-08.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc I feel this version of the RFC 2740 respin is pretty much ready for WG last call. Please take a look as soon as possible. My intent is to start the WG last call soon after IETF 65 in Dallas. Internet-Drafts@IETF.ORG wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : OSPF for IPv6 > Author(s) : D. Ferguson, et al. > Filename : draft-ietf-ospf-ospfv3-update-08.txt > Pages : 98 > Date : 2006-3-2 > >This document describes the modifications to OSPF to support version >6 of the Internet Protocol (IPv6). The fundamental mechanisms of >OSPF (flooding, DR election, area support, SPF calculations, etc.) >remain unchanged. However, some changes have been necessary, either >due to changes in protocol semantics between IPv4 and IPv6, or simply >to handle the increased address size of IPv6. > >Changes between OSPF for IPv4 and this document include the >following. Addressing semantics have been removed from OSPF packets >and the basic LSAs. New LSAs have been created to carry IPv6 >addresses and prefixes. OSPF now runs on a per-link basis rather >than on a per-IP-subnet basis. Flooding scope for LSAs has been >generalized. Authentication has been removed from the OSPF protocol >and instead relies on IPv6's Authentication Header and Encapsulating >Security Payload. > >Even with larger IPv6 packet, most packets in OSPF for IPv6 are >almost as compact as those in OSPF for IPv4. Most fields and packet- >size limitations present in OSPF for IPv4 have been relaxed. In >addition, option handling has been made more flexible. > >All of OSPF for IPv4's optional capabilities, including demand >circuit support, NSSA areas, and the multicast extensions to OSPF >(MOSPF) are also supported in OSPF for IPv6. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-08.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ospf-ospfv3-update-08.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-08.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 02 20:17:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyvI-0007qN-NR for ospf-archive@LISTS.IETF.ORG; Thu, 02 Mar 2006 20:17:36 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEyvG-00030M-GY for ospf-archive@LISTS.IETF.ORG; Thu, 02 Mar 2006 20:17:36 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0003BC41@wildebeest.ease.lsoft.com>; Thu, 2 Mar 2006 20:17:33 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-SBRS:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Content-Transfer-Encoding:Content-Type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=lufy0YPTARfLUp31qD+odDox4NwkTpkUYZ2mhDM4FbizrJejmKo2wlcKfXOx3utOUfaKDWxD6b4hPrh4+I/cGAheBDFSfjJoGjzrdJPZRC1fl/YbehVVxXMtac/m7deS; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 100864051 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 2 Mar 2006 20:17:33 -0500 Received: from 204.154.129.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 2 Mar 2006 20:07:32 -0500 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 03 Mar 2006 01:07:32 +0000 X-SBRS: None X-IronPort-AV: i="4.02,161,1139184000"; d="scan'208"; a="46147113:sNHT180836500" Received: from ussj1wms2.tellabs-west.tellabsinc.net ([172.25.6.30]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Mar 2006 19:07:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on the OSPFv3 MIB : draft-ietf-ospf-ospfv3-mib-10.txt Thread-Index: AcY+PY51bP1mIidHR42WqAJ4kwkxvwAHwt5Q X-OriginalArrivalTime: 03 Mar 2006 01:07:31.0889 (UTC) FILETIME=[D9393210:01C63E5E] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Message-ID: <0551D846F0819D4F9BD6EF2E7D18D59B773DF6@ussj1wms2> Date: Thu, 2 Mar 2006 17:07:30 -0800 Reply-To: Mailing List Sender: Mailing List From: "Goyal, Manoj" Subject: Questions on the OSPFv3 MIB : draft-ietf-ospf-ospfv3-mib-10.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi, In the ospfV3 MIB I don't see the ospf instance ID being used properly as the index. As per the ospfv3 RFC, the entire ospf lsdb, areas and spf stuff is per instance(though is does not state it clearly). Each instance is logically a separate entity from other instance running on the same box. In the MIB draft: INDEX { ospfv3AreaId }=20 ::=3D { ospfv3AreaTable 1 } Why isn't the instance ID a index in the area table? When a get is done, what instance's area is accessed. If the next is done do you go to the same area-id of next instance? Rather it should be the next area of the same instance. Shouldn't the instance ID be the first index in all the tables? The same is the case with other tables too where the instanceId should be there. Thanks, Manoj =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 02 23:10:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF1cx-0008OF-K9 for ospf-archive@LISTS.IETF.ORG; Thu, 02 Mar 2006 23:10:51 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF1cx-0000wi-9C for ospf-archive@LISTS.IETF.ORG; Thu, 02 Mar 2006 23:10:51 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.0003BDE0@wildebeest.ease.lsoft.com>; Thu, 2 Mar 2006 23:10:50 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=n2/JKvx+vI+Eh/YtY4LbNvy2uaWGKeXEUBrjWCwhtUXl58AM+feGZtDiOSZtJhqcyYDcxuBa3ZpG/CvFYZcc99aNm6gQfMIoqSpEeT8IQ805KaTTAUOgNKGf8edJwNNO; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 100873736 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 2 Mar 2006 23:10:50 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 2 Mar 2006 23:10:50 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2006 20:10:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,162,1139212800"; d="scan'208"; a="22904314:sNHT23673072" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k234AnVU001427 for ; Thu, 2 Mar 2006 23:10:49 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 23:10:49 -0500 Received: from [10.82.209.35] ([10.82.209.35]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 23:10:49 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <0551D846F0819D4F9BD6EF2E7D18D59B773DF6@ussj1wms2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 04:10:49.0069 (UTC) FILETIME=[740DB1D0:01C63E78] Message-ID: <4407C1C8.5080401@cisco.com> Date: Thu, 2 Mar 2006 23:10:48 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Questions on the OSPFv3 MIB : draft-ietf-ospf-ospfv3-mib-10.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0551D846F0819D4F9BD6EF2E7D18D59B773DF6@ussj1wms2> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi Manoj, Actually, I believe if one were going to take this approach for supporting multiple OSPFv3 instances, one would have to add instance ID to every OSPFv3 MIB table index and make every scalar MIB variable a table indexed by instance ID. We had this discussion once before for the OSPFv2 MIB and decided against it, in part, due to the fact that RFC 1850 was already published. At that time, the solution we pointed to was to use different SNMPv3 contexts to access MIB variables for separate protocol instances. However, I don't believe the specifics were ever standardized. Thanks, Acee Goyal, Manoj wrote: >Hi, >In the ospfV3 MIB I don't see the ospf instance ID being >used properly as the index. >As per the ospfv3 RFC, the entire ospf lsdb, areas and spf stuff >is per instance(though is does not state it clearly). >Each instance is logically a separate entity >from other instance running on the same box. >In the MIB draft: > >INDEX { ospfv3AreaId } > ::= { ospfv3AreaTable 1 } > >Why isn't the instance ID a index in the area table? When a get >is done, what instance's area is accessed. If the next is done >do you go to the same area-id of next instance? Rather it should be >the next area of the same instance. >Shouldn't the instance ID be the first index in all the tables? > >The same is the case with other tables too where the instanceId should >be there. > >Thanks, >Manoj >============================================================ >The information contained in this message may be privileged >and confidential and protected from disclosure. If the reader >of this message is not the intended recipient, or an employee >or agent responsible for delivering this message to the >intended recipient, you are hereby notified that any reproduction, >dissemination or distribution of this communication is strictly >prohibited. If you have received this communication in error, >please notify us immediately by replying to the message and >deleting it from your computer. Thank you. Tellabs >============================================================ > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 03 18:50:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFK2B-0006jl-Bi for ospf-archive@LISTS.IETF.ORG; Fri, 03 Mar 2006 18:50:07 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFK2A-0003BJ-3Y for ospf-archive@LISTS.IETF.ORG; Fri, 03 Mar 2006 18:50:07 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.0003C28A@wildebeest.ease.lsoft.com>; Fri, 3 Mar 2006 18:50:05 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:Content-Type:Mime-Version:Message-ID:Date:Reply-To:Sender:From:Subject:Comments:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=X6B5GlD3r+L5qqGNK9SN80OGHUe7FUw6ZP8e6QosoU9q7KqpmybeQ7ffX633mq01fN8QsDK4bxkm2tWx8jJFEZUkEqzMEnbkgiabG3qsI38FMdhSxoi1JQNTWp/HunVo; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 100976770 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 3 Mar 2006 18:50:05 -0500 Received: from 209.173.53.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 3 Mar 2006 18:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k23No2BX000579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Mar 2006 23:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FFK26-0000fK-CN; Fri, 03 Mar 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Fri, 3 Mar 2006 18:50:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@IETF.ORG Subject: I-D ACTION:draft-ietf-ospf-ospfv3-graceful-restart-03.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPFv3 Graceful Restart Author(s) : P. Pillay-Esnault, A. Lindem Filename : draft-ietf-ospf-ospfv3-graceful-restart-03.txt Pages : 11 Date : 2006-3-3 This memo describes the OSPFv3 graceful restart. For OSPFv3, graceful restart is identical to OSPFv2 except for the differences described in this memo. These differences include the format of the grace Link State Advertisements (LSA) and other considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-graceful-restart-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-3155034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-graceful-restart-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-3155034.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 05 13:19:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFxpY-0003gi-U9 for ospf-archive@LISTS.IETF.ORG; Sun, 05 Mar 2006 13:19:44 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFxpX-0005bF-Oa for ospf-archive@LISTS.IETF.ORG; Sun, 05 Mar 2006 13:19:44 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.0003C56A@wildebeest.ease.lsoft.com>; 5 Mar 2006 13:19:40 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=Km2QThlw2g/H7wN8hGjbQ+K6/k0B8cHnA6KZRAMrO/igmcXTANgwgFSEsoxIyxz2sry8/AGw0BA4gv0q98JW/LTrvrauA70VAEMiYW2Pa07/owQ/falmRqR6i1mCxaQs; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101122906 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 5 Mar 2006 13:19:40 -0500 Received: from 64.233.166.177 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 5 Mar 2006 13:19:40 -0500 Received: by pproxy.gmail.com with SMTP id x66so871306pye for ; Sun, 05 Mar 2006 10:19:39 -0800 (PST) Received: by 10.65.160.10 with SMTP id m10mr1719548qbo; Sun, 05 Mar 2006 10:19:39 -0800 (PST) Received: by 10.65.124.7 with HTTP; Sun, 5 Mar 2006 10:19:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: Date: Sun, 5 Mar 2006 13:19:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramanan N Subject: redistributing default route ? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi For the following config in a OSPF router, ... ip route 0.0.0.0 0.0.0.0 null0 ... router ospf 1 redistribute static network x.x.x.x ... ... 1. should OSPF redistribute the static default route (0/0) in its ASE ? 2. or OSPF should redistribute this default route only if the command "default-info originate" is present ? TIA, Ramanan From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 05 14:10:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFyct-0005Zy-RS for ospf-archive@LISTS.IETF.ORG; Sun, 05 Mar 2006 14:10:43 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFycs-00071M-Jy for ospf-archive@LISTS.IETF.ORG; Sun, 05 Mar 2006 14:10:43 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0003C50A@wildebeest.ease.lsoft.com>; 5 Mar 2006 14:10:42 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=dw0Qqsa/71301GzlPMKeEeeE915DBHBamL+AFkjd8i8hgwV07B0+qF6fv7p1Hd9DIMXxcShyf/+yrSpgVIbLqdVAFJ5xNstZazGmHIiW8j0/dETKyI6QEF3fLyw2Zk3X; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101124899 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 5 Mar 2006 14:10:41 -0500 Received: from 171.71.176.117 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 5 Mar 2006 14:10:41 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 05 Mar 2006 11:10:41 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k25JAe7T026629 for ; Sun, 5 Mar 2006 11:10:40 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Mar 2006 14:10:40 -0500 Received: from [10.82.209.35] ([10.82.209.35]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Mar 2006 14:10:39 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2006 19:10:39.0752 (UTC) FILETIME=[7DD5A080:01C64088] Message-ID: <440B37AF.6040703@cisco.com> Date: Sun, 5 Mar 2006 14:10:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: redistributing default route ? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi Ramanan, OSPF redistribution (or import/export) policy is a local matter and not covered by RFC 2328. Thanks, Acee Ramanan N wrote: >Hi > >For the following config in a OSPF router, >... >ip route 0.0.0.0 0.0.0.0 null0 >... > >router ospf 1 >redistribute static >network x.x.x.x ... >... > >1. should OSPF redistribute the static default route (0/0) in its ASE ? >2. or OSPF should redistribute this default route only if the command >"default-info originate" is present ? > >TIA, >Ramanan > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 05 19:23:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG3Vy-0003qg-Er for ospf-archive@LISTS.IETF.ORG; Sun, 05 Mar 2006 19:23:54 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG3Vx-0007ip-6K for ospf-archive@LISTS.IETF.ORG; Sun, 05 Mar 2006 19:23:54 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0003C469@wildebeest.ease.lsoft.com>; 5 Mar 2006 19:23:52 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:References:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=RTta8kD5YXT2wiEo2EIZOAJUCEeQgJLXsah/5HvTYDpbl8muBG188AalgIT0Re4C1TuBp5bjOVm2lAsTsTEGEzxmNmoQyKKKyjZ6NbEl1I5gXt6973Sd+gaUyfY2SrME; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101141676 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 5 Mar 2006 19:23:52 -0500 Received: from 64.233.162.192 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 5 Mar 2006 19:23:25 -0500 Received: by zproxy.gmail.com with SMTP id f1so1098571nzc for ; Sun, 05 Mar 2006 16:23:25 -0800 (PST) Received: by 10.65.121.11 with SMTP id y11mr2342359qbm; Sun, 05 Mar 2006 16:23:25 -0800 (PST) Received: by 10.65.124.7 with HTTP; Sun, 5 Mar 2006 16:23:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <440B37AF.6040703@cisco.com> Message-ID: Date: Sun, 5 Mar 2006 19:23:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramanan N Subject: Re: redistributing default route ? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <440B37AF.6040703@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Thanks Acee. I was wondering if there was atleast one implementation doing the redistribution of static default route. Please let me know if there is any such implementation. General idea is to avoid the static default route redistribution to safeguard the network. Ramanan On 3/5/06, Acee Lindem wrote: > Hi Ramanan, > > OSPF redistribution (or import/export) policy is a local matter and not > covered by RFC 2328. > > Thanks, > Acee > > Ramanan N wrote: > > >Hi > > > >For the following config in a OSPF router, > >... > >ip route 0.0.0.0 0.0.0.0 null0 > >... > > > >router ospf 1 > >redistribute static > >network x.x.x.x ... > >... > > > >1. should OSPF redistribute the static default route (0/0) in its ASE ? > >2. or OSPF should redistribute this default route only if the command > >"default-info originate" is present ? > > > >TIA, > >Ramanan > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 05 19:42:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG3ni-0002dd-Tu for ospf-archive@LISTS.IETF.ORG; Sun, 05 Mar 2006 19:42:14 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG3nh-00007s-NT for ospf-archive@LISTS.IETF.ORG; Sun, 05 Mar 2006 19:42:14 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0003C50D@wildebeest.ease.lsoft.com>; 5 Mar 2006 19:42:13 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:MIME-Version:References:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date:Reply-To:Sender:From:Subject:Comments:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=fRr7YPYHBqpaPPidGNt8hIP7PVf7mORfUtUVg0Wq1irj+STKYXGS3LJcejkzOK17b9qJy9+YWQKBx/BD/JSlZHgpjqTxk1gmXSc41siJvewoA7OeVeM3obT4f4yr/Paa; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101142044 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 5 Mar 2006 19:42:13 -0500 Received: from 63.240.77.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 5 Mar 2006 19:32:13 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with ESMTP id <2006030600321201200j3sb5e>; Mon, 6 Mar 2006 00:32:12 +0000 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 References: <440B37AF.6040703@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <440B82E4.8020207@tony.li> Date: Sun, 5 Mar 2006 16:31:32 -0800 Reply-To: Mailing List Sender: Mailing List From: Tony Li Subject: Re: redistributing default route ? Comments: To: Ramanan N To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c This list is intended for OSPF protocol standardization discussions, not for customer support or market research. Respectfully, Tony Ramanan N wrote: > Thanks Acee. > I was wondering if there was atleast one implementation > doing the redistribution of static default route. > Please let me know if there is any such implementation. > > General idea is to avoid the static default route redistribution > to safeguard the network. > > Ramanan > > On 3/5/06, Acee Lindem wrote: >> Hi Ramanan, >> >> OSPF redistribution (or import/export) policy is a local matter and not >> covered by RFC 2328. >> >> Thanks, >> Acee >> >> Ramanan N wrote: >> >>> Hi >>> >>> For the following config in a OSPF router, >>> ... >>> ip route 0.0.0.0 0.0.0.0 null0 >>> ... >>> >>> router ospf 1 >>> redistribute static >>> network x.x.x.x ... >>> ... >>> >>> 1. should OSPF redistribute the static default route (0/0) in its ASE ? >>> 2. or OSPF should redistribute this default route only if the command >>> "default-info originate" is present ? >>> >>> TIA, >>> Ramanan >>> >>> >>> > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 06 10:43:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHpC-0007pp-7o for ospf-archive@LISTS.IETF.ORG; Mon, 06 Mar 2006 10:40:42 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGHfn-0005zR-SW for ospf-archive@LISTS.IETF.ORG; Mon, 06 Mar 2006 10:31:01 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.0003C92E@wildebeest.ease.lsoft.com>; Mon, 6 Mar 2006 10:30:59 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-test-idtracker:Message-ID:Date:Reply-To:Sender:From:Subject:Comments:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=qyO3IY/8U7VNiumftAU2lg5ARwZncZEz29Y8At780YI9jts9JAMkP+alrEzFV0sU5gcKnxPcQwWcgW0vQTMbUK/wlCJ1PwBSV8n8Y6Qjq305VTfL83rK/9j4efE1rdBz; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101210364 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 6 Mar 2006 10:30:58 -0500 Received: from 209.173.57.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 6 Mar 2006 10:30:23 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k26FUMvP006966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Mar 2006 15:30:22 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGHfC-00067s-II; Mon, 06 Mar 2006 10:30:22 -0500 X-test-idtracker: no Message-ID: Date: Mon, 6 Mar 2006 10:30:22 -0500 Reply-To: Mailing List Sender: Mailing List From: The IESG Subject: Last Call: 'OSPF Version 2 Management Information Base' to Proposed Standard Comments: To: IETF-Announce To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 The IESG has received a request from the Open Shortest Path First IGP WG to consider the following document: - 'OSPF Version 2 Management Information Base ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-09.txt From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 13:54:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3nm-00020X-Fs for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 13:54:26 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3nl-00046C-7g for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 13:54:26 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0003D415@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 13:54:24 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=BdY8LZIWAtD7DOb6145ARFEq8Y5t1GKaI2WuIA9K/dw12JOjcG1uN5/mvs9tsda8NcCZsv4An2S1NoxLiwO8958cnRaHISexHRA1jUFmDVWw38Sv0CkRxPCjjIJC8UST; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101482077 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 13:54:25 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 13:54:25 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2006 10:53:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,176,1139212800"; d="scan'208"; a="23225522:sNHT25154424" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k28IrNWc024917 for ; Wed, 8 Mar 2006 13:53:23 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 13:53:23 -0500 Received: from [10.82.241.99] ([10.82.241.99]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 13:53:23 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 18:53:23.0333 (UTC) FILETIME=[9351E350:01C642E1] Message-ID: <440F2822.2000401@cisco.com> Date: Wed, 8 Mar 2006 13:53:22 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: IETF 65 Draft Agenda To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I've uploaded the agenda for the OSPF WG meeting in Dallas. We have a longer slot this time so they'll be some extra time for discussion. We'll continue the charter update discussion (and potentially others) on the list for those of you who cannot attend. Open Shortest Path First WG (ospf) Thursday, March 23rd from 0900-1130 ==================================== CHAIR(s): Rohit Dube Acee Lindem AGENDA: o Administriva 5 minutes - Mailing list: OSPF@PEACH.EASE.LSOFT.COM Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 - Scribe? - Blue Sheets o Document Status - Acee 10 minutes o Immediate Reply Hello - Zengjie Kou 15 minutes draft-kou-ospf-immediately-replying-hello-00.txt o OSPF MPR Extension - Emmanuel Baccelli 15 minutes draft-baccelli-ospf-mpr-ext-01.txt o OSPF MDR Draft Update - Tom Henderson for Richard Ogier draft-ogier-ospf-manet-extension-07.txt 15 minutes o OSPF MDR Position - Tom Henderson for Richard Ogier draft-ogier-ospf-mdr-position-00.txt 15 minutes o oSPF MANET Design Team Progress/Next Steps (Tom) 20 minutes o OSPF WG Charter - Acee 10 minutes o OSPF WG Charter Discussion 10 minutes Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 15:33:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5Lf-0000wg-KV for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 15:33:31 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5Le-0007rN-ED for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 15:33:31 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0003D562@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 15:33:29 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:Content-Type:Content-Transfer-Encoding:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=EqJ2O4fSWP5OpEWY0lj/2jJMvN2y8dK+/BzmZHJbQcVhRBfJt/07dxxL5lDsHxGf0ju4fF/J0lfWJQDfUcxLp9yv7xtGgJQBNiYSupSGxkHE6TjYPgOVeHueUw0K3+J+; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101488803 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 15:33:30 -0500 Received: from 207.17.137.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 15:33:30 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 08 Mar 2006 12:33:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,176,1139212800"; d="scan'208"; a="532451611:sNHT23016644" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 12:33:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding the P bit in type-7 LSA Thread-Index: AcZC74Uz86HEHWrUR/K2vizAxQgkPA== X-OriginalArrivalTime: 08 Mar 2006 20:33:13.0360 (UTC) FILETIME=[85A77900:01C642EF] Message-ID: Date: Wed, 8 Mar 2006 12:33:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Sunil Patro Subject: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 From section 3.4 of rfc 1587(The OSPF NSSA Option), "If a router is attached to another AS and is also an NSSA area border router, it may originate a both a type-5 and a type-7 LSA for the same network. The type-5 LSA will be flooded to the backbone (and all attached type-5 capable areas) and the type-7 will be flooded into the NSSA. If this is the case, the P-bit must be reset in the type-7 NSSA so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA area border router." Can someone throw some light on why the P bit must be clear in the case when an ASBR originates both a type 7 and type 5 LSA for the same network? Thanks in advance. Sunil From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 15:48:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5aS-0005Z2-TE for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 15:48:48 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5aR-0008AE-Mw for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 15:48:48 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0003D54C@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 15:48:47 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=P7WJmkL6xvzKQIBosNm4oA5SbOd9RhpKtEBuWXrxtMUW2tbwOee5yXY1rAZCAL5SXWmqQ2s5FA1agZYtH08iH4GigIeNClalUpnJO7fygdqSSUVv5j12YU9xKasMNilK; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101489682 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 15:48:48 -0500 Received: from 158.130.12.194 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 15:48:47 -0500 Received: from ee.upenn.edu (M367PC1.cis.upenn.edu [158.130.53.77]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id k28Kmfwj013878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Mar 2006 15:48:41 -0500 User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <440F4329.6060207@ee.upenn.edu> Date: Wed, 8 Mar 2006 15:48:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Roch Guerin Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 The NSSA ABR that originates both the T5 and T7 may not be the designated translator for the NSSA and it would be superfluous to have another translation of the T7 flooded as a T5 in the backbone. Note: You should be looking at RFC 3101 which obsoltes RFC 1587. >>From section 3.4 of rfc 1587(The OSPF NSSA Option), > > "If a router is attached to another AS and is also an NSSA area border > router, it may originate a both a type-5 and a type-7 LSA for the > same network. The type-5 LSA will be flooded to the backbone (and > all attached type-5 capable areas) and the type-7 will be flooded > into the NSSA. If this is the case, the P-bit must be reset in the > type-7 NSSA so the type-7 LSA isn't again translated into a type-5 > LSA by another NSSA area border router." > > >Can someone throw some light on why the P bit must be clear in the case >when an ASBR originates both a type 7 and type 5 LSA for the same >network? > >Thanks in advance. >Sunil > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 15:49:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5bJ-0006Ri-CO for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 15:49:41 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5bJ-0008FX-4i for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 15:49:41 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0003D54D@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 15:49:40 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:Content-Type:References:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=Rtd/Fi1t/5cFPJv/mziKgTOI4EehHJL5JWnX4K+eoSxqW6LkYW465gEq5BG1/QHpcS3HZ2xOIygOxmXONthcw0LGA1+oz8Was0HE3v+EjmyVIK9bzVSv4rPIV8h1Sfa9; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101489717 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 15:49:41 -0500 Received: from 66.249.82.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 15:49:41 -0500 Received: by xproxy.gmail.com with SMTP id i28so203089wxd for ; Wed, 08 Mar 2006 12:49:40 -0800 (PST) Received: by 10.70.34.19 with SMTP id h19mr1308959wxh; Wed, 08 Mar 2006 12:49:39 -0800 (PST) Received: by 10.70.7.2 with HTTP; Wed, 8 Mar 2006 12:49:39 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8729_28928930.1141850979921" References: Message-ID: <77ead0ec0603081249o51229627sc4b522ccf46bff19@mail.gmail.com> Date: Wed, 8 Mar 2006 12:49:39 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.5 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 ------=_Part_8729_28928930.1141850979921 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sunil, Acee may not be able to reply till the evening, so let me give it a try in the mean while. "If this is the case, the P-bit must be reset in the type-7 NSSA so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA area border router." Isnt the reason embedded in the question you ask? I guess we do not want to originate multiple Type-5 LSA's for the same destination and that is the reason for the P-bit setting. Thanks, Vishwas On 3/8/06, Sunil Patro wrote: > > From section 3.4 of rfc 1587(The OSPF NSSA Option), > > "If a router is attached to another AS and is also an NSSA area border > router, it may originate a both a type-5 and a type-7 LSA for the > same network. The type-5 LSA will be flooded to the backbone (and > all attached type-5 capable areas) and the type-7 will be flooded > into the NSSA. If this is the case, the P-bit must be reset in the > type-7 NSSA so the type-7 LSA isn't again translated into a type-5 > LSA by another NSSA area border router." > > > Can someone throw some light on why the P bit must be clear in the case > when an ASBR originates both a type 7 and type 5 LSA for the same > network? > > Thanks in advance. > Sunil > ------=_Part_8729_28928930.1141850979921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sunil,

Acee may not be able to reply till the evening, so let me give it a try in = the mean while.

"If this is the case, the P-bit must be reset in the  type-7 NSSA so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA area border router."

Isnt the reason embedded in the question you ask?

I guess we do not want to originate multiple Type-5 LSA's for the same dest= ination and that is the reason for the P-bit setting.

Thanks,
Vishwas

On 3/8/06, Sunil Patro <sunilp@juniper.net> wrote:
From section 3.4 of rfc 1587(The OSPF NSSA Option),

  &quo= t;If a router is attached to another AS and is also an NSSA area border
=    router, it may originate a both a type-5 and a type-7 LSA for = the
   same network.  The type-5 LSA will be flooded= to the backbone (and
   all attached type-5 capable areas) and the type-7 will be = flooded
   into the NSSA.  If this is the case, the = P-bit must be reset in the
   type-7 NSSA so the type-7 LSA is= n't again translated into a type-5
   LSA by another NSSA area border router."


Can s= omeone throw some light on why the P bit must be clear in the case
when = an ASBR originates both a type 7 and type 5 LSA for the same
network?
Thanks in advance.
Sunil

------=_Part_8729_28928930.1141850979921-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 15:50:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5bh-0007FN-J4 for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 15:50:05 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5bh-0008I1-BA for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 15:50:05 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.0003D578@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 15:50:04 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:Content-Type:Mime-Version:Message-ID:Date:Reply-To:Sender:From:Subject:Comments:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=gcvuZivzqnJo1UTg3QalSxIF2YL2j6a92owOlals4Zey2uMpDt0+6rfzTRacZcLdXn6m2b6UKiTJLp7h2NKFLonclcwpUK0xXFRScnXAH4FXdN92RMe5UN/ZxYB0/INv; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101489733 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 15:50:05 -0500 Received: from 209.173.57.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko30e006069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5bf-0002sC-6J; Wed, 08 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Wed, 8 Mar 2006 15:50:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@IETF.ORG Subject: I-D ACTION:draft-ietf-ospf-af-alt-03.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Support of address families in OSPFv3 Author(s) : S. Mirtorabi, et al. Filename : draft-ietf-ospf-af-alt-03.txt Pages : 13 Date : 2006-3-8 This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AF's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-af-alt-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-af-alt-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-af-alt-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-8142959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-af-alt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-af-alt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8142959.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 17:00:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6hj-00019x-Oo for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 17:00:23 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6hh-0002kq-BM for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 17:00:23 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0003D4DD@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 16:50:20 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:Content-Type:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=mXU7cycOUaIwEgvtupKPoXPC7aiHYdb8esLUok85l4Se9TeyDs2CO7m5TameyB/03Le5uiu/LQFGCcJEs1CHAzhoWFsJuTheHwdP0IDCj3E/jvdjDVSmtWom/e98tYlL; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101494338 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 16:50:20 -0500 Received: from 207.17.137.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 16:50:14 -0500 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 08 Mar 2006 13:50:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208,217"; a="535132870:sNHT111923302" Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 13:50:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C642FA.46502ACA" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding the P bit in type-7 LSA Thread-Index: AcZC89/m8DXmVqhAQhaKNaeKp4TAlAABZcOw X-OriginalArrivalTime: 08 Mar 2006 21:50:11.0866 (UTC) FILETIME=[467F8FA0:01C642FA] Message-ID: Date: Wed, 8 Mar 2006 13:50:11 -0800 Reply-To: Mailing List Sender: Mailing List From: Sunil Patro Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b This is a multi-part message in MIME format. ------_=_NextPart_001_01C642FA.46502ACA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does generating multiple type-5 LSAs for the same destination create problem in any way? The same could happen if multiple ASBRs generate type-5 LSA for the same network. =20 Coming back to the context again, consider the following network. =20 Area 0 Area 1 (nssa) area 2 (nssa) A------------------------------B----------------------------------C----- ---------------------------------D =20 Area 2's border router D can be either directly connected back to Area 0 again or through a virtual link. In this case, if C generates two type-7 LSAs for a network as an ASBR, the type-7 will be translated to type-5 through B and D at the same time. So, two type-5 LSA for the same network will end up in area 0. How is this case handled then? =20 Thanks Sunil =20 ________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Wednesday, March 08, 2006 12:50 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Question regarding the P bit in type-7 LSA =20 Hi Sunil, Acee may not be able to reply till the evening, so let me give it a try in the mean while. "If this is the case, the P-bit must be reset in the type-7 NSSA so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA area border router." Isnt the reason embedded in the question you ask? I guess we do not want to originate multiple Type-5 LSA's for the same destination and that is the reason for the P-bit setting. Thanks, Vishwas On 3/8/06, Sunil Patro wrote: From section 3.4 of rfc 1587(The OSPF NSSA Option), =09 "If a router is attached to another AS and is also an NSSA area border router, it may originate a both a type-5 and a type-7 LSA for the same network. The type-5 LSA will be flooded to the backbone (and=20 all attached type-5 capable areas) and the type-7 will be flooded into the NSSA. If this is the case, the P-bit must be reset in the type-7 NSSA so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA area border router." =09 =09 Can someone throw some light on why the P bit must be clear in the case when an ASBR originates both a type 7 and type 5 LSA for the same network? =09 Thanks in advance.=20 Sunil =20 ------_=_NextPart_001_01C642FA.46502ACA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does generating multiple type-5 = LSAs for the same destination create problem in any way? The same could happen if = multiple ASBRs generate type-5 LSA for the same = network.

 

Coming back to the context again, = consider the following network.

 

      =   Area = 0            =           Area 1 (nssa)           &= nbsp;  =             area = 2 (nssa)

A------------------------------B----= ------------------------------C--------------------------------------D

 

Area 2’s border router D can = be either directly connected back to Area 0 again or through a virtual = link.

In this case, if C generates two = type-7 LSAs for a network as an ASBR, the type-7 will be translated to type-5 = through B and D at the same time.

So, two type-5 LSA for the same = network will end up in area 0. How is this case handled = then?

 

Thanks

Sunil

 

From: = Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral
Sent: Wednesday, March = 08, 2006 12:50 PM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Question = regarding the P bit in type-7 LSA

 

Hi Sunil,

Acee may not be able to reply till the evening, so let me give it a try = in the mean while.

"If this is the case, the P-bit must be reset in the  type-7 = NSSA so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA = area border router."

Isnt the reason embedded in the question you ask?

I guess we do not want to originate multiple Type-5 LSA's for the same destination and that is the reason for the P-bit setting.

Thanks,
Vishwas

On 3/8/06, Sunil Patro = <sunilp@juniper.net> = wrote:

From section 3.4 of rfc 1587(The OSPF NSSA Option),

  "If a router is attached to another AS and is also an = NSSA area border
   router, it may originate a both a type-5 and a type-7 LSA = for the
   same network.  The type-5 LSA will be flooded to = the backbone (and
   all attached type-5 capable areas) and the type-7 will be = flooded
   into the NSSA.  If this is the case, the P-bit = must be reset in the
   type-7 NSSA so the type-7 LSA isn't again translated into a = type-5
   LSA by another NSSA area border router."


Can someone throw some light on why the P bit must be clear in the = case
when an ASBR originates both a type 7 and type 5 LSA for the same
network?

Thanks in advance.
Sunil

 

------_=_NextPart_001_01C642FA.46502ACA-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 17:12:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6tK-0000Wf-4V for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 17:12:22 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6tJ-0003ub-Nh for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 17:12:22 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.0003D5E0@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 17:12:21 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:Content-Type:References:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=jmoI3TUYVnr5/luZgSmaudzehlDeaqEUySviOw+3+QUjZE4J/GZlEX0FaBy5T5+n+yHnTOrwNxpjkIYoB6dGJPtTpLNtz9MlhTeysh7q4cDmVyYHZIB/D6mE8de2w7uC; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101495836 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 17:12:21 -0500 Received: from 66.249.82.201 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 17:12:21 -0500 Received: by xproxy.gmail.com with SMTP id s10so213452wxc for ; Wed, 08 Mar 2006 14:12:20 -0800 (PST) Received: by 10.70.24.18 with SMTP id 18mr1456178wxx; Wed, 08 Mar 2006 14:12:20 -0800 (PST) Received: by 10.70.7.2 with HTTP; Wed, 8 Mar 2006 14:12:20 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10145_22810545.1141855940305" References: Message-ID: <77ead0ec0603081412x14ba6d56t9a2af5d096f1e8f9@mail.gmail.com> Date: Wed, 8 Mar 2006 14:12:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d ------=_Part_10145_22810545.1141855940305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sunil, Having multiple LSA's for the same destination are not very useful, though they do not create a problem. The topology you refer to looks very interesting but may not ever be that way in the real world. Thanks, Vishwas On 3/8/06, Sunil Patro wrote: > > Does generating multiple type-5 LSAs for the same destination create > problem in any way? The same could happen if multiple ASBRs generate type= -5 > LSA for the same network. > > > > Coming back to the context again, consider the following network. > > > > Area 0 Area 1 (nssa) > area 2 (nssa) > > > A------------------------------B----------------------------------C------= --------------------------------D > > > > Area 2's border router D can be either directly connected back to Area 0 > again or through a virtual link. > > In this case, if C generates two type-7 LSAs for a network as an ASBR, th= e > type-7 will be translated to type-5 through B and D at the same time. > > So, two type-5 LSA for the same network will end up in area 0. How is thi= s > case handled then? > > > > Thanks > > Sunil > > > ------------------------------ > > *From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf Of *Vi= shwas > Manral > *Sent:* Wednesday, March 08, 2006 12:50 PM > *To:* OSPF@PEACH.EASE.LSOFT.COM > *Subject:* Re: Question regarding the P bit in type-7 LSA > > > > Hi Sunil, > > Acee may not be able to reply till the evening, so let me give it a try i= n > the mean while. > > "If this is the case, the P-bit must be reset in the type-7 NSSA so the > type-7 LSA isn't again translated into a type-5 LSA by another NSSA area > border router." > > Isnt the reason embedded in the question you ask? > > I guess we do not want to originate multiple Type-5 LSA's for the same > destination and that is the reason for the P-bit setting. > > Thanks, > Vishwas > > On 3/8/06, *Sunil Patro* wrote: > > From section 3.4 of rfc 1587(The OSPF NSSA Option), > > "If a router is attached to another AS and is also an NSSA area border > router, it may originate a both a type-5 and a type-7 LSA for the > same network. The type-5 LSA will be flooded to the backbone (and > all attached type-5 capable areas) and the type-7 will be flooded > into the NSSA. If this is the case, the P-bit must be reset in the > type-7 NSSA so the type-7 LSA isn't again translated into a type-5 > LSA by another NSSA area border router." > > > Can someone throw some light on why the P bit must be clear in the case > when an ASBR originates both a type 7 and type 5 LSA for the same > network? > > Thanks in advance. > Sunil > > > ------=_Part_10145_22810545.1141855940305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sunil,

Having multiple LSA's for the same destination are not very useful, though = they do not create a problem.

The topology you refer to looks very interesting but may not ever be that w= ay in the real world.

Thanks,
Vishwas

On 3/8/06, Sunil Patro <sun= ilp@juniper.net> wrote:

Does generating multiple type-5 LS= As for the same destination create problem in any way? The same could happen if mu= ltiple ASBRs generate type-5 LSA for the same network.

 

Coming back to the context again, = consider the following network.

 

     &nbs= p;  Area 0            &n= bsp;         Area 1 (nssa)           &nb= sp;              area 2 (nssa)

A------------------------------B--= --------------------------------C--------------------------------------D

 

Area 2's border router D can be either directly connected back to Area 0 again or through a virtual link.

In this case, if C generates two t= ype-7 LSAs for a network as an ASBR, the type-7 will be translated to type-5 thro= ugh B and D at the same time.

So, two type-5 LSA for the same ne= twork will end up in area 0. How is this case handled then?

 

Thanks

Sunil

 

From: Ma= iling List [mailto:OSPF@PEACH.EASE.LSOFT.= COM] On Behalf Of Vishwas Manral
Sent: Wednesday, March 08,= 2006 12:50 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Question rega= rding the P bit in type-7 LSA

 

Hi Sunil,

Acee may not be able to reply till the evening, so let me give it a try in = the mean while.

"If this is the case, the P-bit must be reset in the  type-7 NSSA= so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA are= a border router."

Isnt the reason embedded in the question you ask?

I guess we do not want to originate multiple Type-5 LSA's for the same destination and that is the reason for the P-bit setting.

Thanks,
Vishwas

On 3/8/06, Sunil Patro <= ;sunilp@juniper.net> wrote:

From section 3.4 of rfc 1587(The OSPF NSSA Option),

  "If a router is attached to another AS and is also an NSSA area border
   router, it may originate a both a type-5 and a type-7 LSA for = the
   same network.  The type-5 LSA will be flooded to the backbone (and
   all attached type-5 capable areas) and the type-7 will be floo= ded
   into the NSSA.  If this is the case, the P-bit must = be reset in the
   type-7 NSSA so the type-7 LSA isn't again translated into a ty= pe-5
   LSA by another NSSA area border router."


Can someone throw some light on why the P bit must be clear in the case
when an ASBR originates both a type 7 and type 5 LSA for the same
network?

Thanks in advance.
Sunil

 


------=_Part_10145_22810545.1141855940305-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 19:37:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH9AA-0001Od-PC for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 19:37:55 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH9A9-0003Vc-GS for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 19:37:54 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.0003D690@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 19:37:52 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-SBRS:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:Content-Type:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=btpzlRXZHf9j40XpSzNoL35lHv0uqsOQdQuz+O4QSLIbq8NzuQ64NThwxQrDcly+7flzs6DFxdVSi8n0X6fuNvDQuP+AieLXgS9O1ViBcWhCoFbEwxgTbGta73xWg0hD; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101507655 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 19:37:52 -0500 Received: from 204.154.129.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 19:37:52 -0500 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 09 Mar 2006 00:37:51 +0000 X-SBRS: None X-IronPort-AV: i="4.02,177,1139184000"; d="scan'208,217"; a="46731052:sNHT29975836" Received: from ussj1wms2.tellabs-west.tellabsinc.net ([172.25.6.30]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Mar 2006 18:37:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64311.B2250BA8" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OAPFv3: what is the use of prefixes in Link LSA Thread-Index: AcZC/WCDqIXqdcuBT2u/z/bM+S332gAE8n+Q X-OriginalArrivalTime: 09 Mar 2006 00:37:51.0724 (UTC) FILETIME=[B2A412C0:01C64311] Message-ID: <0551D846F0819D4F9BD6EF2E7D18D59B807BC4@ussj1wms2> Date: Wed, 8 Mar 2006 16:37:50 -0800 Reply-To: Mailing List Sender: Mailing List From: "Goyal, Manoj" Subject: OAPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd This is a multi-part message in MIME format. ------_=_NextPart_001_01C64311.B2250BA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" HI, In ospfv3 the intra-area-prefix LSAs have all the prefixes and routing table should be calculated using them. Then what is really the use of having the prefixes of the link in its link-LSA. Is there a case where the router will not include some prefixes in intra-area-prefix LSA but advertise in the link-LSA? I don't see any such case. =20 Thanks, Manoj =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C64311.B2250BA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

HI,

In ospfv3 the intra-area-prefix LSAs have all the prefix= es and routing table

should be calculated using them. Then what is really the= use of having

the prefixes of the link in its link-LSA.

Is there a case where the router will not include some prefixes in intra-area-prefix LSA

but advertise in the link-LSA? I don’t see any such case.

 

Thanks,

Manoj

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C64311.B2250BA8-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 21:01:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHASe-0004D8-J6 for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 21:01:04 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHASd-0006IT-AE for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 21:01:04 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0003D646@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 21:01:02 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=OLe2jOY7f/dP3yZT8OLfjEm14kRbsdbJlyGxYWtcs209pGw0p30lqau8abV6Tzx247iBU7MCeNze3aPiE6gSe/wV1/UqGa2mnb2pVai3DyYApEHDutLAtv7uOzHaKDp+; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101512106 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 21:01:03 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 21:01:03 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2006 18:01:01 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2920sH3016615 for ; Wed, 8 Mar 2006 18:01:01 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 21:00:56 -0500 Received: from [10.25.187.130] ([10.25.187.130]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 21:00:55 -0500 User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <0551D846F0819D4F9BD6EF2E7D18D59B807BC4@ussj1wms2> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Mar 2006 02:00:55.0936 (UTC) FILETIME=[4D767800:01C6431D] Message-ID: <440F8C55.2080107@cisco.com> Date: Wed, 8 Mar 2006 20:00:53 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Re: OAPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0551D846F0819D4F9BD6EF2E7D18D59B807BC4@ussj1wms2> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi Manoj, Goyal, Manoj wrote: > HI, > > In ospfv3 the intra-area-prefix LSAs have all the prefixes and routing table > > should be calculated using them. Then what is really the use of having > > the prefixes of the link in its link-LSA. For broadcast and nbma links, the prefixes in the link lsas are used by the DR to construct the intra-area prefix lsa associated with the network lsa. > > Is there a case where the router will not include some prefixes in > intra-area-prefix LSA > > but advertise in the link-LSA? I don’t see any such case. Prefixes for broadcast/nbma transit links are advertised by the DR on behalf of the attached routers, and not by the non-DR routers themselves. But if you are asking if some of the prefixes won't appear in _any_ intra-area prefix lsa, then no, I don't think so. Regards, Paul > > > > Thanks, > > Manoj From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 08 21:03:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAVO-0008LH-7H for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 21:03:54 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHAVM-0006Jr-U6 for ospf-archive@LISTS.IETF.ORG; Wed, 08 Mar 2006 21:03:54 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.0003D6DC@wildebeest.ease.lsoft.com>; Wed, 8 Mar 2006 21:03:52 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=LE0m36FI61Hg6+CqNyhg7DasnCp9/t+uWkOC52+T+4akW/M7zQ+ucqRwnWMie94GMb6eqldrX1DGblTner1ixkw5YoTOZsh62vusHXWdO6UsiLavnXiXfzuq7xSsGo11; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101512195 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Mar 2006 21:03:53 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Mar 2006 21:03:53 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2006 18:03:51 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="312789467:sNHT34920876" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2923pGv019751 for ; Wed, 8 Mar 2006 18:03:51 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 21:03:50 -0500 Received: from [10.82.210.44] ([10.82.210.44]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 21:03:50 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77ead0ec0603081412x14ba6d56t9a2af5d096f1e8f9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 02:03:50.0561 (UTC) FILETIME=[B58C2110:01C6431D] Message-ID: <440F8D05.6020804@cisco.com> Date: Wed, 8 Mar 2006 21:03:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <77ead0ec0603081412x14ba6d56t9a2af5d096f1e8f9@mail.gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Vishwas Manral wrote: >Hi Sunil, > >Having multiple LSA's for the same destination are not very useful, though >they do not create a problem. > >The topology you refer to looks very interesting but may not ever be that >way in the real world. > > Hi Sunil, I agree with Vishwas. Additionally, since the non-translator ABR/ASBR is the original source of the route, it makes no sense for the translating ABR to re-advertise it and will only delay convergence should connectivity to the destination be lost. Thanks, Acee >Thanks, >Vishwas > >On 3/8/06, Sunil Patro wrote: > > >> Does generating multiple type-5 LSAs for the same destination create >>problem in any way? The same could happen if multiple ASBRs generate type-5 >>LSA for the same network. >> >> >> >>Coming back to the context again, consider the following network. >> >> >> >> Area 0 Area 1 (nssa) >>area 2 (nssa) >> >> >>A------------------------------B----------------------------------C--------------------------------------D >> >> >> >>Area 2's border router D can be either directly connected back to Area 0 >>again or through a virtual link. >> >>In this case, if C generates two type-7 LSAs for a network as an ASBR, the >>type-7 will be translated to type-5 through B and D at the same time. >> >>So, two type-5 LSA for the same network will end up in area 0. How is this >>case handled then? >> >> >> >>Thanks >> >>Sunil >> >> >> ------------------------------ >> >>*From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf Of *Vishwas >>Manral >>*Sent:* Wednesday, March 08, 2006 12:50 PM >>*To:* OSPF@PEACH.EASE.LSOFT.COM >>*Subject:* Re: Question regarding the P bit in type-7 LSA >> >> >> >>Hi Sunil, >> >>Acee may not be able to reply till the evening, so let me give it a try in >>the mean while. >> >>"If this is the case, the P-bit must be reset in the type-7 NSSA so the >>type-7 LSA isn't again translated into a type-5 LSA by another NSSA area >>border router." >> >>Isnt the reason embedded in the question you ask? >> >>I guess we do not want to originate multiple Type-5 LSA's for the same >>destination and that is the reason for the P-bit setting. >> >>Thanks, >>Vishwas >> >>On 3/8/06, *Sunil Patro* wrote: >> >>From section 3.4 of rfc 1587(The OSPF NSSA Option), >> >> "If a router is attached to another AS and is also an NSSA area border >> router, it may originate a both a type-5 and a type-7 LSA for the >> same network. The type-5 LSA will be flooded to the backbone (and >> all attached type-5 capable areas) and the type-7 will be flooded >> into the NSSA. If this is the case, the P-bit must be reset in the >> type-7 NSSA so the type-7 LSA isn't again translated into a type-5 >> LSA by another NSSA area border router." >> >> >>Can someone throw some light on why the P bit must be clear in the case >>when an ASBR originates both a type 7 and type 5 LSA for the same >>network? >> >>Thanks in advance. >>Sunil >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 09 12:31:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOzF-000529-2o for ospf-archive@LISTS.IETF.ORG; Thu, 09 Mar 2006 12:31:41 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOzE-00010P-Oq for ospf-archive@LISTS.IETF.ORG; Thu, 09 Mar 2006 12:31:41 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0003D74D@wildebeest.ease.lsoft.com>; Thu, 9 Mar 2006 12:31:02 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-SBRS:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Content-Transfer-Encoding:Content-Type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=avrVeD01B+x64IkZd5BZiz4/JLyimdwNZpC2zk3kk6A4LICQFn+ewC8TjpshBS5r0kxnz+gunlpAHNPHs2LGRvxZ/2rP/wKXALGDHO5BaIKYOW+hcaX7Xs2OPg+FSJGU; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101573033 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Mar 2006 12:31:02 -0500 Received: from 204.154.129.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Mar 2006 12:30:40 -0500 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 09 Mar 2006 17:30:38 +0000 X-SBRS: None X-IronPort-AV: i="4.02,179,1139184000"; d="scan'208"; a="46802350:sNHT213581132" Received: from ussj1wms2.tellabs-west.tellabsinc.net ([172.25.6.30]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Mar 2006 11:30:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OAPFv3: what is the use of prefixes in Link LSA Thread-Index: AcZDHVLJ/rIAFHu9RTm6rLu9DBI1OAAgL73A X-OriginalArrivalTime: 09 Mar 2006 17:30:38.0417 (UTC) FILETIME=[2E699410:01C6439F] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Message-ID: <0551D846F0819D4F9BD6EF2E7D18D59B807CEB@ussj1wms2> Date: Thu, 9 Mar 2006 09:30:37 -0800 Reply-To: Mailing List Sender: Mailing List From: "Goyal, Manoj" Subject: Re: OAPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 I think I asked the first question in a wrong way, sure that the link LSAs are used by the DR to construct the IAP-LSA for the broadcast network. But what is the use of the link LSAs having prefixes for P2P links as all the prefixes are present in the router's IAP LSAs already?? Practically most links are P2P. Manoj -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Paul Wells Sent: Wednesday, March 08, 2006 6:01 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OAPFv3: what is the use of prefixes in Link LSA Hi Manoj, Goyal, Manoj wrote: > HI, >=20 > In ospfv3 the intra-area-prefix LSAs have all the prefixes and routing table >=20 > should be calculated using them. Then what is really the use of having >=20 > the prefixes of the link in its link-LSA. For broadcast and nbma links, the prefixes in the link lsas are used by=20 the DR to construct the intra-area prefix lsa associated with the=20 network lsa. >=20 > Is there a case where the router will not include some prefixes in=20 > intra-area-prefix LSA >=20 > but advertise in the link-LSA? I don't see any such case. Prefixes for broadcast/nbma transit links are advertised by the DR on=20 behalf of the attached routers, and not by the non-DR routers=20 themselves. But if you are asking if some of the prefixes won't appear=20 in _any_ intra-area prefix lsa, then no, I don't think so. Regards, Paul >=20 > =20 >=20 > Thanks, >=20 > Manoj =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 09 15:50:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5P-0001YI-Oe for ospf-archive@LISTS.IETF.ORG; Thu, 09 Mar 2006 15:50:15 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS5P-0007FX-G3 for ospf-archive@LISTS.IETF.ORG; Thu, 09 Mar 2006 15:50:15 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0003D8C7@wildebeest.ease.lsoft.com>; Thu, 9 Mar 2006 15:50:14 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:Content-Type:Mime-Version:Message-ID:Date:Reply-To:Sender:From:Subject:Comments:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=jbj3UyIV6YKZGwOG1o1rw6nlFV5IhdsKeHBcf1dz84Voo3NKqeLqLr3Yx8Hh0FznKA4uLF+hMghpIOGV5LfZCCInVDRffbkeKqo2SrNZCJxgRCN3DPqPf3nz9F+tX6Ri; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101594492 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Mar 2006 15:50:07 -0500 Received: from 209.173.57.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Mar 2006 15:50:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko3vP025006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5D-0000Ac-C6; Thu, 09 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Thu, 9 Mar 2006 15:50:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@IETF.ORG Subject: I-D ACTION:draft-ietf-ospf-mt-ospfv3-01.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Multi-topology routing in OSPFv3 (MT-OSPFv3) Author(s) : S. Mirtorabi, A. Roy Filename : draft-ietf-ospf-mt-ospfv3-01.txt Pages : 25 Date : 2006-3-9 This document describes an extensible mechanism to support multiple topologies (MT) in OSPFv3. These topologies can be used within the same address family in order to compute different paths for different classes of service, or belong to different address families allowing an integrated definition of address family with OSPFv3. The extension described in this document can further facilitate any future extensions of OSPFv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-ospfv3-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-mt-ospfv3-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-mt-ospfv3-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-9144321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-ospfv3-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-ospfv3-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9144321.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 09 19:44:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVjr-0007Ln-Gy for ospf-archive@LISTS.IETF.ORG; Thu, 09 Mar 2006 19:44:15 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHVjr-0000xq-8s for ospf-archive@LISTS.IETF.ORG; Thu, 09 Mar 2006 19:44:15 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.0003D97A@wildebeest.ease.lsoft.com>; Thu, 9 Mar 2006 19:44:14 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=aumud9SHCh7ptD5luk4y6ChhayLYIUpw0XqaVn6xKfP17ZozCJyG8AK1zd3eozlXQ3kzknBvwBfV6Txk5CHEX3SSOINzI5zJXP8m3RX6TUzRZT2xyIkKoVWldKPE7PKO; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101606516 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Mar 2006 19:44:14 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Mar 2006 19:44:14 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2006 16:44:14 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="260921576:sNHT31356082" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2A0iB1n007708 for ; Thu, 9 Mar 2006 16:44:13 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 19:44:12 -0500 Received: from [10.82.210.44] ([10.82.210.44]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 19:44:11 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <0551D846F0819D4F9BD6EF2E7D18D59B807CEB@ussj1wms2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 00:44:11.0869 (UTC) FILETIME=[BFA358D0:01C643DB] Message-ID: <4410CBDA.9010300@cisco.com> Date: Thu, 9 Mar 2006 19:44:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OAPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0551D846F0819D4F9BD6EF2E7D18D59B807CEB@ussj1wms2> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Goyal, Manoj wrote: >I think I asked the first question in a wrong way, sure that >the link LSAs are used by the DR to construct the IAP-LSA for the >broadcast network. >But what is the use of the link LSAs having prefixes for >P2P links as all the prefixes are present in the router's >IAP LSAs already?? Practically most links are P2P. > > Hi Manoj, In the RFC 2370 update draft, I added text explicitly stating that link LSAs are not needed for virtual links. I considered saying they MAY be omitted on p2p links as well but was worried that conceivably an implementation could use link LSAs exclusively for next-hop computation (they are needed for next-hop computation on NBMA links). Are there other opinions on this? Thanks, Acee >Manoj > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Paul >Wells >Sent: Wednesday, March 08, 2006 6:01 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: OAPFv3: what is the use of prefixes in Link LSA > >Hi Manoj, > >Goyal, Manoj wrote: > > >>HI, >> >>In ospfv3 the intra-area-prefix LSAs have all the prefixes and routing >> >> >table > > >>should be calculated using them. Then what is really the use of having >> >>the prefixes of the link in its link-LSA. >> >> > >For broadcast and nbma links, the prefixes in the link lsas are used by >the DR to construct the intra-area prefix lsa associated with the >network lsa. > > > >>Is there a case where the router will not include some prefixes in >>intra-area-prefix LSA >> >>but advertise in the link-LSA? I don't see any such case. >> >> > >Prefixes for broadcast/nbma transit links are advertised by the DR on >behalf of the attached routers, and not by the non-DR routers >themselves. But if you are asking if some of the prefixes won't appear >in _any_ intra-area prefix lsa, then no, I don't think so. > >Regards, >Paul > > > >> >> >>Thanks, >> >>Manoj >> >> >============================================================ >The information contained in this message may be privileged >and confidential and protected from disclosure. If the reader >of this message is not the intended recipient, or an employee >or agent responsible for delivering this message to the >intended recipient, you are hereby notified that any reproduction, >dissemination or distribution of this communication is strictly >prohibited. If you have received this communication in error, >please notify us immediately by replying to the message and >deleting it from your computer. Thank you. Tellabs >============================================================ > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 09 20:26:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHWP2-0002Eq-64 for ospf-archive@LISTS.IETF.ORG; Thu, 09 Mar 2006 20:26:48 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHWP1-0002GM-TR for ospf-archive@LISTS.IETF.ORG; Thu, 09 Mar 2006 20:26:48 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.0003D8C1@wildebeest.ease.lsoft.com>; Thu, 9 Mar 2006 20:26:47 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-SBRS:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Content-Transfer-Encoding:Content-Type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=LEMYx7ra1nTkwW7lrxcU/3PbEuhxBivA372lnKbMYLnbHGTuLNdDkv3rkFuW+VIEwUGq2lm5MGRhrAtBEDxdeLt0Q+t4ELCKm8I5rurhgU1W9EXwkPbyfAIY6LjbLOmw; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101608528 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Mar 2006 20:26:47 -0500 Received: from 204.154.129.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Mar 2006 20:26:45 -0500 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 10 Mar 2006 01:26:45 +0000 X-SBRS: None X-IronPort-AV: i="4.02,180,1139184000"; d="scan'208"; a="46850642:sNHT202367100" Received: from ussj1wms2.tellabs-west.tellabsinc.net ([172.25.6.30]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Mar 2006 19:26:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OAPFv3: what is the use of prefixes in Link LSA Thread-Index: AcZD28KgCI3oJbT/Smi90lF3JDv6fgAAbGNQ X-OriginalArrivalTime: 10 Mar 2006 01:26:45.0293 (UTC) FILETIME=[B198EDD0:01C643E1] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Message-ID: <0551D846F0819D4F9BD6EF2E7D18D59B807FC8@ussj1wms2> Date: Thu, 9 Mar 2006 17:26:43 -0800 Reply-To: Mailing List Sender: Mailing List From: "Goyal, Manoj" Subject: Re: OAPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Hi Acee, I feel a description could be added to make it clear that: - the link LSAs are only required for broadcast and NBMA links. - for p2p links they are not required (or optional) - and if a link LSA is generated for a link that is p2p, then it should not include any prefixes as they are already available in intra-area-prefix LSAs. Even for the implementation purpose, during route calculation, getting the link-local address on a p2p link though its neighbor is quicker/easier then parsing the link-lsa of the neighbor to get the link-local address from there. Thanks, Manoj -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Thursday, March 09, 2006 4:44 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OAPFv3: what is the use of prefixes in Link LSA Goyal, Manoj wrote: >I think I asked the first question in a wrong way, sure that >the link LSAs are used by the DR to construct the IAP-LSA for the >broadcast network. >But what is the use of the link LSAs having prefixes for >P2P links as all the prefixes are present in the router's >IAP LSAs already?? Practically most links are P2P. > =20 > Hi Manoj, In the RFC 2370 update draft, I added text explicitly stating that link=20 LSAs are not needed for virtual links. I considered saying they MAY be omitted on p2p links as well but was worried that conceivably an implementation=20 could use link LSAs exclusively for next-hop computation (they are needed for=20 next-hop computation on NBMA links). Are there other opinions on this? Thanks, Acee >Manoj > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Paul >Wells >Sent: Wednesday, March 08, 2006 6:01 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: OAPFv3: what is the use of prefixes in Link LSA > >Hi Manoj, > >Goyal, Manoj wrote: > =20 > >>HI, >> >>In ospfv3 the intra-area-prefix LSAs have all the prefixes and routing >> =20 >> >table > =20 > >>should be calculated using them. Then what is really the use of having >> >>the prefixes of the link in its link-LSA. >> =20 >> > >For broadcast and nbma links, the prefixes in the link lsas are used by >the DR to construct the intra-area prefix lsa associated with the=20 >network lsa. > > =20 > >>Is there a case where the router will not include some prefixes in=20 >>intra-area-prefix LSA >> >>but advertise in the link-LSA? I don't see any such case. >> =20 >> > >Prefixes for broadcast/nbma transit links are advertised by the DR on=20 >behalf of the attached routers, and not by the non-DR routers=20 >themselves. But if you are asking if some of the prefixes won't appear >in _any_ intra-area prefix lsa, then no, I don't think so. > >Regards, >Paul > > =20 > >>=20 >> >>Thanks, >> >>Manoj >> =20 >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >The information contained in this message may be privileged >and confidential and protected from disclosure. If the reader >of this message is not the intended recipient, or an employee >or agent responsible for delivering this message to the >intended recipient, you are hereby notified that any reproduction, >dissemination or distribution of this communication is strictly >prohibited. If you have received this communication in error, >please notify us immediately by replying to the message and >deleting it from your computer. Thank you. Tellabs >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 10 14:32:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHnLR-0006jW-18 for ospf-archive@LISTS.IETF.ORG; Fri, 10 Mar 2006 14:32:13 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHnLQ-0001Uj-Gk for ospf-archive@LISTS.IETF.ORG; Fri, 10 Mar 2006 14:32:13 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0003DC3A@wildebeest.ease.lsoft.com>; Fri, 10 Mar 2006 14:32:10 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:Content-Type:Content-Transfer-Encoding:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=qSD3QW939SMzTJXBonU97vbYjE2WBYJbht/QYLW7jYeLWfwS25eLUEuVm7oJXMPKaHH+DGws5qGsAEWpusZxxPoeOGvuhpEJkGA18PZ5TfiOXk/RqyPOzwFGbj6+NISU; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101701518 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Mar 2006 14:32:05 -0500 Received: from 207.17.137.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Mar 2006 14:29:35 -0500 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 10 Mar 2006 11:29:35 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,181,1139212800"; d="scan'208"; a="532883451:sNHT25223284" Received: from hadron.jnpr.net ([172.24.15.25]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 11:29:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding the P bit in type-7 LSA Thread-Index: AcZDHfNC/3c1l3uWTmWcot8eD9fAzQBWhY4w X-OriginalArrivalTime: 10 Mar 2006 19:29:34.0061 (UTC) FILETIME=[F60031D0:01C64478] Message-ID: Date: Fri, 10 Mar 2006 11:29:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Sunil Patro Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 So, it looks like it is more of an optimization to reset the P bit in type-7 LSA in the case of an originated type-5 LSA also by the ASBR. But Acee, if you look at my example topology below, it still allows for a case where we could still land up with multiple type-5 LSA for the same network even with the ASBR going by the RFC rules of resetting the P bit in type-7 LSA. Also, don't you think the statement of resetting the P bit in the RFC should be "SHOULD" instead of "MUST"?=20 Thanks, Sunil > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee > Lindem > Sent: Wednesday, March 08, 2006 6:04 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Question regarding the P bit in type-7 LSA >=20 > Vishwas Manral wrote: >=20 > >Hi Sunil, > > > >Having multiple LSA's for the same destination are not very useful, > though > >they do not create a problem. > > > >The topology you refer to looks very interesting but may not ever be that > >way in the real world. > > > > > Hi Sunil, > I agree with Vishwas. Additionally, since the non-translator ABR/ASBR > is the original source of the route, it makes no sense for the > translating ABR to re-advertise it > and will only delay convergence should connectivity to the destination > be lost. >=20 > Thanks, > Acee >=20 > >Thanks, > >Vishwas > > > >On 3/8/06, Sunil Patro wrote: > > > > > >> Does generating multiple type-5 LSAs for the same destination create > >>problem in any way? The same could happen if multiple ASBRs generate > type-5 > >>LSA for the same network. > >> > >> > >> > >>Coming back to the context again, consider the following network. > >> > >> > >> > >> Area 0 Area 1 (nssa) > >>area 2 (nssa) > >> > >> > >>A------------------------------B----------------------------------C--- -- > ---------------------------------D > >> > >> > >> > >>Area 2's border router D can be either directly connected back to Area 0 > >>again or through a virtual link. > >> > >>In this case, if C generates two type-7 LSAs for a network as an ASBR, > the > >>type-7 will be translated to type-5 through B and D at the same time. > >> > >>So, two type-5 LSA for the same network will end up in area 0. How is > this > >>case handled then? > >> > >> > >> > >>Thanks > >> > >>Sunil > >> > >> > >> ------------------------------ > >> > >>*From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf Of > *Vishwas > >>Manral > >>*Sent:* Wednesday, March 08, 2006 12:50 PM > >>*To:* OSPF@PEACH.EASE.LSOFT.COM > >>*Subject:* Re: Question regarding the P bit in type-7 LSA > >> > >> > >> > >>Hi Sunil, > >> > >>Acee may not be able to reply till the evening, so let me give it a try > in > >>the mean while. > >> > >>"If this is the case, the P-bit must be reset in the type-7 NSSA so the > >>type-7 LSA isn't again translated into a type-5 LSA by another NSSA area > >>border router." > >> > >>Isnt the reason embedded in the question you ask? > >> > >>I guess we do not want to originate multiple Type-5 LSA's for the same > >>destination and that is the reason for the P-bit setting. > >> > >>Thanks, > >>Vishwas > >> > >>On 3/8/06, *Sunil Patro* wrote: > >> > >>From section 3.4 of rfc 1587(The OSPF NSSA Option), > >> > >> "If a router is attached to another AS and is also an NSSA area border > >> router, it may originate a both a type-5 and a type-7 LSA for the > >> same network. The type-5 LSA will be flooded to the backbone (and > >> all attached type-5 capable areas) and the type-7 will be flooded > >> into the NSSA. If this is the case, the P-bit must be reset in the > >> type-7 NSSA so the type-7 LSA isn't again translated into a type-5 > >> LSA by another NSSA area border router." > >> > >> > >>Can someone throw some light on why the P bit must be clear in the case > >>when an ASBR originates both a type 7 and type 5 LSA for the same > >>network? > >> > >>Thanks in advance. > >>Sunil > >> > >> > >> > >> > >> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 10 15:20:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHo6U-0007Sq-Qm for ospf-archive@LISTS.IETF.ORG; Fri, 10 Mar 2006 15:20:50 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHo6U-0002gq-1c for ospf-archive@LISTS.IETF.ORG; Fri, 10 Mar 2006 15:20:50 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0003DB2C@wildebeest.ease.lsoft.com>; Fri, 10 Mar 2006 15:20:48 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=R7ethUZw7g24Otg7uolxXce1D6EwsUAJe80/JZbfElNv0RnmI5PrMz763TMivGqM4BqAa9zVwGejtSYxq/w0//jZnRA8SimWxcRf7eM1vp4V+nnid8HcNzBZVQd+2PNj; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101705670 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Mar 2006 15:20:43 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Mar 2006 15:20:35 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2006 15:20:34 -0500 X-IronPort-AV: i="4.02,181,1139202000"; d="scan'208"; a="83891982:sNHT58261760" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2AKKXWc009075 for ; Fri, 10 Mar 2006 15:20:33 -0500 (EST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Mar 2006 15:20:32 -0500 Received: from [10.25.187.130] ([10.25.187.130]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Mar 2006 15:20:32 -0500 User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 20:20:32.0531 (UTC) FILETIME=[14FDAE30:01C64480] Message-ID: <4411DF8E.3060403@cisco.com> Date: Fri, 10 Mar 2006 14:20:30 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Hi Sunil, Let me try to redraw your topology with the link between D and the backbone shown to make sure I understand your point: area 0 area 1 area 2 nssa nssa A--------B--------C--------D | asbr | | | +-----------------+ area 0 In this case C generates type-7 lsas with the P bit set and floods them to B and D in areas 1 and 2 respectively. B and D will indeed translate these into two separate type 5 lsas. However, this is necessary given the topology, as these two lsas are not functionally identical (different transit areas). If, say, D were to not do the translation for some reason, then the external routes would be unreachable if the B-C link went down. In the case in which we're talking about resetting the P bit, the redundant type 5 lsas don't add any new information, since both would use the same area to reach the asbr. Thanks, Paul Sunil Patro wrote: > So, it looks like it is more of an optimization to reset the P bit in > type-7 LSA in the case of an originated type-5 LSA also by the ASBR. > > But Acee, if you look at my example topology below, it still allows for > a case where we could still land up with multiple type-5 LSA for the > same network even with the ASBR going by the RFC rules of resetting the > P bit in type-7 LSA. > > Also, don't you think the statement of resetting the P bit in the RFC > should be "SHOULD" instead of "MUST"? > > Thanks, > Sunil > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Acee > >>Lindem >>Sent: Wednesday, March 08, 2006 6:04 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Question regarding the P bit in type-7 LSA >> >>Vishwas Manral wrote: >> >> >>>Hi Sunil, >>> >>>Having multiple LSA's for the same destination are not very useful, >> >>though >> >>>they do not create a problem. >>> >>>The topology you refer to looks very interesting but may not ever be > > that > >>>way in the real world. >>> >>> >> >>Hi Sunil, >>I agree with Vishwas. Additionally, since the non-translator ABR/ASBR >>is the original source of the route, it makes no sense for the >>translating ABR to re-advertise it >>and will only delay convergence should connectivity to the destination >>be lost. >> >>Thanks, >>Acee >> >> >>>Thanks, >>>Vishwas >>> >>>On 3/8/06, Sunil Patro wrote: >>> >>> >>> >>>>Does generating multiple type-5 LSAs for the same destination > > create > >>>>problem in any way? The same could happen if multiple ASBRs generate >> >>type-5 >> >>>>LSA for the same network. >>>> >>>> >>>> >>>>Coming back to the context again, consider the following network. >>>> >>>> >>>> >>>> Area 0 Area 1 (nssa) >>>>area 2 (nssa) >>>> >>>> >> >>>A------------------------------B----------------------------------C--- > > -- > >>---------------------------------D >> >>>> >>>> >>>>Area 2's border router D can be either directly connected back to > > Area 0 > >>>>again or through a virtual link. >>>> >>>>In this case, if C generates two type-7 LSAs for a network as an > > ASBR, > >>the >> >>>>type-7 will be translated to type-5 through B and D at the same > > time. > >>>>So, two type-5 LSA for the same network will end up in area 0. How > > is > >>this >> >>>>case handled then? >>>> >>>> >>>> >>>>Thanks >>>> >>>>Sunil >>>> >>>> >>>> ------------------------------ >>>> >>>>*From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf > > Of > >>*Vishwas >> >>>>Manral >>>>*Sent:* Wednesday, March 08, 2006 12:50 PM >>>>*To:* OSPF@PEACH.EASE.LSOFT.COM >>>>*Subject:* Re: Question regarding the P bit in type-7 LSA >>>> >>>> >>>> >>>>Hi Sunil, >>>> >>>>Acee may not be able to reply till the evening, so let me give it a > > try > >>in >> >>>>the mean while. >>>> >>>>"If this is the case, the P-bit must be reset in the type-7 NSSA so > > the > >>>>type-7 LSA isn't again translated into a type-5 LSA by another NSSA > > area > >>>>border router." >>>> >>>>Isnt the reason embedded in the question you ask? >>>> >>>>I guess we do not want to originate multiple Type-5 LSA's for the > > same > >>>>destination and that is the reason for the P-bit setting. >>>> >>>>Thanks, >>>>Vishwas >>>> >>>>On 3/8/06, *Sunil Patro* wrote: >>>> >>> >>>>From section 3.4 of rfc 1587(The OSPF NSSA Option), >>> >>>> "If a router is attached to another AS and is also an NSSA area > > border > >>>> router, it may originate a both a type-5 and a type-7 LSA for the >>>> same network. The type-5 LSA will be flooded to the backbone > > (and > >>>> all attached type-5 capable areas) and the type-7 will be flooded >>>> into the NSSA. If this is the case, the P-bit must be reset in > > the > >>>> type-7 NSSA so the type-7 LSA isn't again translated into a > > type-5 > >>>> LSA by another NSSA area border router." >>>> >>>> >>>>Can someone throw some light on why the P bit must be clear in the > > case > >>>>when an ASBR originates both a type 7 and type 5 LSA for the same >>>>network? >>>> >>>>Thanks in advance. >>>>Sunil >>>> >>>> >>>> >>>> >>>> >>> >>> >>> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 10 16:35:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHpH8-0004ps-4K for ospf-archive@LISTS.IETF.ORG; Fri, 10 Mar 2006 16:35:54 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHpH7-0000H4-P5 for ospf-archive@LISTS.IETF.ORG; Fri, 10 Mar 2006 16:35:54 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0003DCBD@wildebeest.ease.lsoft.com>; Fri, 10 Mar 2006 16:35:53 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:Content-Type:Content-Transfer-Encoding:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=XX01FC6M0x6AzvBAAdudY+8kabc2GP0ixSUvRYrRyVul0gKX11E6kD/nxr0GZ9UTWlJ1LSplkPxmU0Bnn6oB4lzJJJuXLyacMP/9OBt0mBfKFyOxeM1SQiwO6rClam4y; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 101708312 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Mar 2006 16:35:47 -0500 Received: from 207.17.137.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Mar 2006 16:27:05 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 10 Mar 2006 13:27:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,181,1139212800"; d="scan'208"; a="535613497:sNHT26282404" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 13:27:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding the P bit in type-7 LSA Thread-Index: AcZEgCzTH7+eJ6CBTvaAWNsRVsPGbwABHY6g X-OriginalArrivalTime: 10 Mar 2006 21:27:04.0383 (UTC) FILETIME=[6051F4F0:01C64489] Message-ID: Date: Fri, 10 Mar 2006 13:27:04 -0800 Reply-To: Mailing List Sender: Mailing List From: Sunil Patro Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Hi Paul, Please see inline. > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Paul > Wells > Sent: Friday, March 10, 2006 12:21 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Question regarding the P bit in type-7 LSA >=20 > Hi Sunil, >=20 > Let me try to redraw your topology with the link between D and the > backbone shown to make sure I understand your point: >=20 > area 0 area 1 area 2 > nssa nssa > A--------B--------C--------D > | asbr | > | | > +-----------------+ > area 0 >=20 > In this case C generates type-7 lsas with the P bit set and floods them > to B and D in areas 1 and 2 respectively. B and D will indeed translate > these into two separate type 5 lsas. However, this is necessary given > the topology, as these two lsas are not functionally identical > (different transit areas). If, say, D were to not do the translation > for some reason, then the external routes would be unreachable if the > B-C link went down. >=20 Type-7 to type-5 translation is done only if type-7 LSA has non-zero forwarding addresses. So, what extra information does the type-5 LSA generated by D give to area 0 routers? I would think area 0 routers will get the same information from type-5 LSA whether it comes from B or D. As I see, even if D did not do translation, external destinations will be still reachable even if B-C link went down because area 0 routers care about connectivity to ASBR (in this case C), which is in no way dependent upon type-5 LSA generated by D. Am I missing something here? > In the case in which we're talking about resetting the P bit, the > redundant type 5 lsas don't add any new information, since both would > use the same area to reach the asbr. area 0 area 1 =20 nssa A--------B--------C (NSSA translator) | asbr | | | +-----------------+ Area 0 I am drawing the topology above (the case we are interested in for resetting the P -bit) to visualize it better. I see the obvious reason in the above case that database size will become unnecessarily big because of C translating type-7 into a type-5, which is the reason mentioned in NSSA RFC that multiple NSSA area border translators are not recommended. Does the same reason apply to our case? Thanks, Sunil >=20 > Thanks, > Paul >=20 > Sunil Patro wrote: > > So, it looks like it is more of an optimization to reset the P bit in > > type-7 LSA in the case of an originated type-5 LSA also by the ASBR. > > > > But Acee, if you look at my example topology below, it still allows for > > a case where we could still land up with multiple type-5 LSA for the > > same network even with the ASBR going by the RFC rules of resetting the > > P bit in type-7 LSA. > > > > Also, don't you think the statement of resetting the P bit in the RFC > > should be "SHOULD" instead of "MUST"? > > > > Thanks, > > Sunil > > > > > >>-----Original Message----- > >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > > > Acee > > > >>Lindem > >>Sent: Wednesday, March 08, 2006 6:04 PM > >>To: OSPF@PEACH.EASE.LSOFT.COM > >>Subject: Re: Question regarding the P bit in type-7 LSA > >> > >>Vishwas Manral wrote: > >> > >> > >>>Hi Sunil, > >>> > >>>Having multiple LSA's for the same destination are not very useful, > >> > >>though > >> > >>>they do not create a problem. > >>> > >>>The topology you refer to looks very interesting but may not ever be > > > > that > > > >>>way in the real world. > >>> > >>> > >> > >>Hi Sunil, > >>I agree with Vishwas. Additionally, since the non-translator ABR/ASBR > >>is the original source of the route, it makes no sense for the > >>translating ABR to re-advertise it > >>and will only delay convergence should connectivity to the destination > >>be lost. > >> > >>Thanks, > >>Acee > >> > >> > >>>Thanks, > >>>Vishwas > >>> > >>>On 3/8/06, Sunil Patro wrote: > >>> > >>> > >>> > >>>>Does generating multiple type-5 LSAs for the same destination > > > > create > > > >>>>problem in any way? The same could happen if multiple ASBRs generate > >> > >>type-5 > >> > >>>>LSA for the same network. > >>>> > >>>> > >>>> > >>>>Coming back to the context again, consider the following network. > >>>> > >>>> > >>>> > >>>> Area 0 Area 1 (nssa) > >>>>area 2 (nssa) > >>>> > >>>> > >> > >>>A------------------------------B----------------------------------C-- - > > > > -- > > > >>---------------------------------D > >> > >>>> > >>>> > >>>>Area 2's border router D can be either directly connected back to > > > > Area 0 > > > >>>>again or through a virtual link. > >>>> > >>>>In this case, if C generates two type-7 LSAs for a network as an > > > > ASBR, > > > >>the > >> > >>>>type-7 will be translated to type-5 through B and D at the same > > > > time. > > > >>>>So, two type-5 LSA for the same network will end up in area 0. How > > > > is > > > >>this > >> > >>>>case handled then? > >>>> > >>>> > >>>> > >>>>Thanks > >>>> > >>>>Sunil > >>>> > >>>> > >>>> ------------------------------ > >>>> > >>>>*From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf > > > > Of > > > >>*Vishwas > >> > >>>>Manral > >>>>*Sent:* Wednesday, March 08, 2006 12:50 PM > >>>>*To:* OSPF@PEACH.EASE.LSOFT.COM > >>>>*Subject:* Re: Question regarding the P bit in type-7 LSA > >>>> > >>>> > >>>> > >>>>Hi Sunil, > >>>> > >>>>Acee may not be able to reply till the evening, so let me give it a > > > > try > > > >>in > >> > >>>>the mean while. > >>>> > >>>>"If this is the case, the P-bit must be reset in the type-7 NSSA so > > > > the > > > >>>>type-7 LSA isn't again translated into a type-5 LSA by another NSSA > > > > area > > > >>>>border router." > >>>> > >>>>Isnt the reason embedded in the question you ask? > >>>> > >>>>I guess we do not want to originate multiple Type-5 LSA's for the > > > > same > > > >>>>destination and that is the reason for the P-bit setting. > >>>> > >>>>Thanks, > >>>>Vishwas > >>>> > >>>>On 3/8/06, *Sunil Patro* wrote: > >>>> > >>> > >>>>From section 3.4 of rfc 1587(The OSPF NSSA Option), > >>> > >>>> "If a router is attached to another AS and is also an NSSA area > > > > border > > > >>>> router, it may originate a both a type-5 and a type-7 LSA for the > >>>> same network. The type-5 LSA will be flooded to the backbone > > > > (and > > > >>>> all attached type-5 capable areas) and the type-7 will be flooded > >>>> into the NSSA. If this is the case, the P-bit must be reset in > > > > the > > > >>>> type-7 NSSA so the type-7 LSA isn't again translated into a > > > > type-5 > > > >>>> LSA by another NSSA area border router." > >>>> > >>>> > >>>>Can someone throw some light on why the P bit must be clear in the > > > > case > > > >>>>when an ASBR originates both a type 7 and type 5 LSA for the same > >>>>network? > >>>> > >>>>Thanks in advance. > >>>>Sunil > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 13 13:34:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrry-00024V-4U for ospf-archive@LISTS.IETF.ORG; Mon, 13 Mar 2006 13:34:14 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrrw-00005O-QV for ospf-archive@LISTS.IETF.ORG; Mon, 13 Mar 2006 13:34:14 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0003E0D5@wildebeest.ease.lsoft.com>; Mon, 13 Mar 2006 13:24:22 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-test-idtracker:Message-ID:Date:Reply-To:Sender:From:Subject:Comments:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=qHGqfqD0Bt9daHtPIzean4+SgVP+Muj+aYO6leyAeY2s4iHN0q9ssYSfG9MLZ4Kzlh5SLlbNcpL6Ts3PVIb40aBUXgHiPZkTsBU9WrptdRJp79CWvN/N1u1Ggbuj1MMv; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102019990 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Mar 2006 13:24:19 -0500 Received: from 209.173.53.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Mar 2006 13:11:48 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2DIBiBX026420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2006 18:11:44 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FIrWC-0003Di-Qx; Mon, 13 Mar 2006 13:11:44 -0500 X-test-idtracker: no Message-ID: Date: Mon, 13 Mar 2006 13:11:44 -0500 Reply-To: Mailing List Sender: Mailing List From: The IESG Subject: Protocol Action: 'Authentication/Confidentiality for OSPFv3' to Proposed Standard Comments: To: IETF-Announce Comments: cc: Internet Architecture Board , RFC Editor , ospf chair , ospf chair To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 The IESG has approved the following document: - 'Authentication/Confidentiality for OSPFv3 ' as a Proposed Standard This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt Technical Summary This document describes mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. In Open Shortest Path First - Version 3 (OSPFv3) for IPv6, authentication fields have been removed from the OSPF headers. When running over IPv6, OSPF relies on the IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Payload (ESP) to ensure integrity, authentication and/or confidentiality of routing exchanges. Working Group Summary There was consensus within the working group to publish this document on the Standards track. Protocol Quality Bill Fenner reviewed this document for the IESG. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 13 16:39:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIukx-0004xp-Mj for ospf-archive@LISTS.IETF.ORG; Mon, 13 Mar 2006 16:39:11 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIukv-0006Je-5y for ospf-archive@LISTS.IETF.ORG; Mon, 13 Mar 2006 16:39:11 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.0003E232@wildebeest.ease.lsoft.com>; Mon, 13 Mar 2006 16:39:07 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=H99N+mVAl1eTAJS5mxjgATg0iwjY93H6sfPN07oL10epkvhTX7MU2SaLPW3o/5VH6AAXMDktbMpCu/WQdfe9jz4pEzKL30TSueFwpnF30JzqqGipjnCJaYFC86swENr4; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102038928 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Mar 2006 16:39:07 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Mar 2006 16:36:23 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Mar 2006 13:36:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,188,1139212800"; d="scan'208"; a="23515892:sNHT26805888" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2DLaMVU022273 for ; Mon, 13 Mar 2006 16:36:22 -0500 (EST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 16:36:21 -0500 Received: from [128.107.163.203] ([128.107.163.203]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 16:36:21 -0500 User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 21:36:21.0620 (UTC) FILETIME=[2BB2D340:01C646E6] Message-ID: <4415E5D6.6090206@cisco.com> Date: Mon, 13 Mar 2006 15:36:22 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Hi Sunil, Responses inline. Sunil Patro wrote: > Hi Paul, > > Please see inline. > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Paul > >>Wells >>Sent: Friday, March 10, 2006 12:21 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Question regarding the P bit in type-7 LSA >> >>Hi Sunil, >> >>Let me try to redraw your topology with the link between D and the >>backbone shown to make sure I understand your point: >> >> area 0 area 1 area 2 >> nssa nssa >>A--------B--------C--------D >> | asbr | >> | | >> +-----------------+ >> area 0 >> >>In this case C generates type-7 lsas with the P bit set and floods > > them > >>to B and D in areas 1 and 2 respectively. B and D will indeed > > translate > >>these into two separate type 5 lsas. However, this is necessary given >>the topology, as these two lsas are not functionally identical >>(different transit areas). If, say, D were to not do the translation >>for some reason, then the external routes would be unreachable if the >>B-C link went down. >> > > > Type-7 to type-5 translation is done only if type-7 LSA has non-zero > forwarding addresses. So, what extra information does the type-5 LSA > generated by D give to area 0 routers? I would think area 0 routers will > get the same information from type-5 LSA whether it comes from B or D. > As I see, even if D did not do translation, external destinations will > be still reachable even if B-C link went down because area 0 routers > care about connectivity to ASBR (in this case C), which is in no way > dependent upon type-5 LSA generated by D. > > Am I missing something here? It's true that the type-7s and the translated type-5s will have forwarding addresses, however they will most likely be different forwarding addresses. This is probably getting into implementation details, but I would expect that the type-7 lsa that C originates into area 1 will have a forwarding address in that area, and similarly for area 2. The end result is that the two translated type-5s are not functionally identical. One advertises a path through area 1 while the other is through area 2, just as if the forwarding address was not present and the advertising router id of the translator was used. Note that the alternate abr behavior of rfc 3509 comes into play here as well. In fact, the topology we are talking about is presented as figure 2 in that rfc. For implementations that follow 3509, C won't be originating summaries between area 1 and 2, so a forwarding address in the other area won't route through C. > > >>In the case in which we're talking about resetting the P bit, the >>redundant type 5 lsas don't add any new information, since both would >>use the same area to reach the asbr. > > > area 0 area 1 > nssa > A--------B--------C (NSSA translator) > | asbr | > | | > +-----------------+ > Area 0 > > I am drawing the topology above (the case we are interested in for > resetting the P -bit) to visualize it better. > > I see the obvious reason in the above case that database size will > become unnecessarily big because of C translating type-7 into a type-5, > which is the reason mentioned in NSSA RFC that multiple NSSA area border > translators are not recommended. Does the same reason apply to our case? I'm not sure I understand that last question. In the above case, B is both an asbr and abr (3509 does not apply). So, the type-5 originated by B into area 0 is sufficient for backbone routers. For routers in area 1, the type-7 is sufficient. If C were to translate the type-7 to a type-5 (with a forwarding address) I don't think it would give routers in the backbone any additional information about how to reach the external routes imported by B. I think the basic goal remains keeping the lsdb as small as possible (but no smaller :-), especially since type-5/7 lsas can be quite numerous. Or did I misunderstand your question? Thanks, Paul > > Thanks, > Sunil > > >>Thanks, >>Paul >> >>Sunil Patro wrote: >> >>>So, it looks like it is more of an optimization to reset the P bit > > in > >>>type-7 LSA in the case of an originated type-5 LSA also by the ASBR. >>> >>>But Acee, if you look at my example topology below, it still allows > > for > >>>a case where we could still land up with multiple type-5 LSA for the >>>same network even with the ASBR going by the RFC rules of resetting > > the > >>>P bit in type-7 LSA. >>> >>>Also, don't you think the statement of resetting the P bit in the > > RFC > >>>should be "SHOULD" instead of "MUST"? >>> >>>Thanks, >>>Sunil >>> >>> >>> >>>>-----Original Message----- >>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>> >>>Acee >>> >>> >>>>Lindem >>>>Sent: Wednesday, March 08, 2006 6:04 PM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: Re: Question regarding the P bit in type-7 LSA >>>> >>>>Vishwas Manral wrote: >>>> >>>> >>>> >>>>>Hi Sunil, >>>>> >>>>>Having multiple LSA's for the same destination are not very useful, >>>> >>>>though >>>> >>>> >>>>>they do not create a problem. >>>>> >>>>>The topology you refer to looks very interesting but may not ever > > be > >>>that >>> >>> >>>>>way in the real world. >>>>> >>>>> >>>> >>>>Hi Sunil, >>>>I agree with Vishwas. Additionally, since the non-translator > > ABR/ASBR > >>>>is the original source of the route, it makes no sense for the >>>>translating ABR to re-advertise it >>>>and will only delay convergence should connectivity to the > > destination > >>>>be lost. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>>>Thanks, >>>>>Vishwas >>>>> >>>>>On 3/8/06, Sunil Patro wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Does generating multiple type-5 LSAs for the same destination >>> >>>create >>> >>> >>>>>>problem in any way? The same could happen if multiple ASBRs > > generate > >>>>type-5 >>>> >>>> >>>>>>LSA for the same network. >>>>>> >>>>>> >>>>>> >>>>>>Coming back to the context again, consider the following network. >>>>>> >>>>>> >>>>>> >>>>>> Area 0 Area 1 (nssa) >>>>>>area 2 (nssa) >>>>>> >>>>>> >>>> >>>>A------------------------------B----------------------------------C-- > > - > >>>-- >>> >>> >>>>---------------------------------D >>>> >>>> >>>>>> >>>>>>Area 2's border router D can be either directly connected back to >>> >>>Area 0 >>> >>> >>>>>>again or through a virtual link. >>>>>> >>>>>>In this case, if C generates two type-7 LSAs for a network as an >>> >>>ASBR, >>> >>> >>>>the >>>> >>>> >>>>>>type-7 will be translated to type-5 through B and D at the same >>> >>>time. >>> >>> >>>>>>So, two type-5 LSA for the same network will end up in area 0. How >>> >>>is >>> >>> >>>>this >>>> >>>> >>>>>>case handled then? >>>>>> >>>>>> >>>>>> >>>>>>Thanks >>>>>> >>>>>>Sunil >>>>>> >>>>>> >>>>>>------------------------------ >>>>>> >>>>>>*From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf >>> >>>Of >>> >>> >>>>*Vishwas >>>> >>>> >>>>>>Manral >>>>>>*Sent:* Wednesday, March 08, 2006 12:50 PM >>>>>>*To:* OSPF@PEACH.EASE.LSOFT.COM >>>>>>*Subject:* Re: Question regarding the P bit in type-7 LSA >>>>>> >>>>>> >>>>>> >>>>>>Hi Sunil, >>>>>> >>>>>>Acee may not be able to reply till the evening, so let me give it > > a > >>>try >>> >>> >>>>in >>>> >>>> >>>>>>the mean while. >>>>>> >>>>>>"If this is the case, the P-bit must be reset in the type-7 NSSA > > so > >>>the >>> >>> >>>>>>type-7 LSA isn't again translated into a type-5 LSA by another > > NSSA > >>>area >>> >>> >>>>>>border router." >>>>>> >>>>>>Isnt the reason embedded in the question you ask? >>>>>> >>>>>>I guess we do not want to originate multiple Type-5 LSA's for the >>> >>>same >>> >>> >>>>>>destination and that is the reason for the P-bit setting. >>>>>> >>>>>>Thanks, >>>>>>Vishwas >>>>>> >>>>>>On 3/8/06, *Sunil Patro* wrote: >>>>>> >>>>> >>>>>>From section 3.4 of rfc 1587(The OSPF NSSA Option), >>>>> >>>>> >>>>>>"If a router is attached to another AS and is also an NSSA area >>> >>>border >>> >>> >>>>>> router, it may originate a both a type-5 and a type-7 LSA for > > the > >>>>>> same network. The type-5 LSA will be flooded to the backbone >>> >>>(and >>> >>> >>>>>> all attached type-5 capable areas) and the type-7 will be > > flooded > >>>>>> into the NSSA. If this is the case, the P-bit must be reset in >>> >>>the >>> >>> >>>>>> type-7 NSSA so the type-7 LSA isn't again translated into a >>> >>>type-5 >>> >>> >>>>>> LSA by another NSSA area border router." >>>>>> >>>>>> >>>>>>Can someone throw some light on why the P bit must be clear in the >>> >>>case >>> >>> >>>>>>when an ASBR originates both a type 7 and type 5 LSA for the same >>>>>>network? >>>>>> >>>>>>Thanks in advance. >>>>>>Sunil >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 14 00:26:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ23J-0005tJ-N5 for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 00:26:37 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ23J-0004Oh-CP for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 00:26:37 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.0003E2FE@wildebeest.ease.lsoft.com>; Tue, 14 Mar 2006 0:26:35 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=WMbU0ppwfe7aBW0sy5nFT/D3AL08tAQrWO1j7wg803RxyfqO4d/zqwZnPYfRoRT9XzX8fgp4rDrBaFSZ507imc/+TRT2xbtd3dACbMqiwzSlLtMMTy5WeH/ztgatSeHf; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102097314 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 00:26:36 -0500 Received: from 171.71.176.117 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Mar 2006 00:26:27 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 13 Mar 2006 21:26:24 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2E5QO7T000104 for ; Mon, 13 Mar 2006 21:26:24 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 00:26:23 -0500 Received: from [10.82.240.171] ([10.82.240.171]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 00:26:23 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <0551D846F0819D4F9BD6EF2E7D18D59B807FC8@ussj1wms2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 05:26:23.0719 (UTC) FILETIME=[D5759F70:01C64727] Message-ID: <4415D8D2.7030106@cisco.com> Date: Mon, 13 Mar 2006 15:40:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OAPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0551D846F0819D4F9BD6EF2E7D18D59B807FC8@ussj1wms2> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.2 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Hi Manoj, Goyal, Manoj wrote: >Hi Acee, >I feel a description could be added to make it clear that: > >- the link LSAs are only required for broadcast and NBMA links. >- for p2p links they are not required (or optional) >- and if a link LSA is generated for a link that is p2p, > then it should not include any prefixes as they are already > available in intra-area-prefix LSAs. > >Even for the implementation purpose, during route calculation, >getting the link-local address on a p2p link though its neighbor >is quicker/easier then parsing the link-lsa of the neighbor >to get the link-local address from there. > > I'd certainly agree here - also you don't really need the next-hop address on a p2p link. However, I'd hate to render an existing RFC 2740 implementation incompatible without at least a knob. I do not, however, see much value to including the global prefixes in the link LSA for p2p or p2mp links. Any other opinions here? Thanks, Acee >Thanks, >Manoj > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Thursday, March 09, 2006 4:44 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: OAPFv3: what is the use of prefixes in Link LSA > >Goyal, Manoj wrote: > > > >>I think I asked the first question in a wrong way, sure that >>the link LSAs are used by the DR to construct the IAP-LSA for the >>broadcast network. >>But what is the use of the link LSAs having prefixes for >>P2P links as all the prefixes are present in the router's >>IAP LSAs already?? Practically most links are P2P. >> >> >> >> >Hi Manoj, > >In the RFC 2370 update draft, I added text explicitly stating that link >LSAs are not >needed for virtual links. I considered saying they MAY be omitted >on p2p links as well but was worried that conceivably an implementation >could >use link LSAs exclusively for next-hop computation (they are needed for >next-hop >computation on NBMA links). Are there other opinions on this? > >Thanks, >Acee > > > >>Manoj >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Paul >>Wells >>Sent: Wednesday, March 08, 2006 6:01 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: OAPFv3: what is the use of prefixes in Link LSA >> >>Hi Manoj, >> >>Goyal, Manoj wrote: >> >> >> >> >>>HI, >>> >>>In ospfv3 the intra-area-prefix LSAs have all the prefixes and routing >>> >>> >>> >>> >>table >> >> >> >> >>>should be calculated using them. Then what is really the use of having >>> >>>the prefixes of the link in its link-LSA. >>> >>> >>> >>> >>For broadcast and nbma links, the prefixes in the link lsas are used by >> >> > > > >>the DR to construct the intra-area prefix lsa associated with the >>network lsa. >> >> >> >> >> >>>Is there a case where the router will not include some prefixes in >>>intra-area-prefix LSA >>> >>>but advertise in the link-LSA? I don't see any such case. >>> >>> >>> >>> >>Prefixes for broadcast/nbma transit links are advertised by the DR on >>behalf of the attached routers, and not by the non-DR routers >>themselves. But if you are asking if some of the prefixes won't appear >> >> > > > >>in _any_ intra-area prefix lsa, then no, I don't think so. >> >>Regards, >>Paul >> >> >> >> >> >>>Thanks, >>> >>>Manoj >>> >>> >>> >>> >>============================================================ >>The information contained in this message may be privileged >>and confidential and protected from disclosure. If the reader >>of this message is not the intended recipient, or an employee >>or agent responsible for delivering this message to the >>intended recipient, you are hereby notified that any reproduction, >>dissemination or distribution of this communication is strictly >>prohibited. If you have received this communication in error, >>please notify us immediately by replying to the message and >>deleting it from your computer. Thank you. Tellabs >>============================================================ >> >> >> >> >> >============================================================ >The information contained in this message may be privileged >and confidential and protected from disclosure. If the reader >of this message is not the intended recipient, or an employee >or agent responsible for delivering this message to the >intended recipient, you are hereby notified that any reproduction, >dissemination or distribution of this communication is strictly >prohibited. If you have received this communication in error, >please notify us immediately by replying to the message and >deleting it from your computer. Thank you. Tellabs >============================================================ > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 14 00:26:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ23K-0005tl-59 for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 00:26:38 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ23J-0004Oh-OJ for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 00:26:38 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0003E34E@wildebeest.ease.lsoft.com>; Tue, 14 Mar 2006 0:26:35 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=Hgv+Bhr9LgNlbwZs016nT3Y5uDB+z4VzxSDwgrXHNdcHOBsHEKMy2e/GrGsk0Vd0mxUWM56x3jkpiZsXtViNdv5J+73WHyEfKQMrPpfElq3InMeE68WWo6JKT2qVn7ja; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102097321 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 00:26:36 -0500 Received: from 171.71.176.117 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Mar 2006 00:26:27 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 13 Mar 2006 21:26:25 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2E5QPw3018153 for ; Mon, 13 Mar 2006 21:26:25 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 00:26:25 -0500 Received: from [10.82.240.171] ([10.82.240.171]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 00:26:24 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 05:26:25.0032 (UTC) FILETIME=[D63DF880:01C64727] Message-ID: <4415DA78.6070409@cisco.com> Date: Mon, 13 Mar 2006 15:47:52 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.2 (/) X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981 Hi Sunil, Sunil Patro wrote: >Hi Paul, > >Please see inline. > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> >> >Paul > > >>Wells >>Sent: Friday, March 10, 2006 12:21 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Question regarding the P bit in type-7 LSA >> >>Hi Sunil, >> >>Let me try to redraw your topology with the link between D and the >>backbone shown to make sure I understand your point: >> >> area 0 area 1 area 2 >> nssa nssa >>A--------B--------C--------D >> | asbr | >> | | >> +-----------------+ >> area 0 >> >>In this case C generates type-7 lsas with the P bit set and floods >> >> >them > > >>to B and D in areas 1 and 2 respectively. B and D will indeed >> >> >translate > > >>these into two separate type 5 lsas. However, this is necessary given >>the topology, as these two lsas are not functionally identical >>(different transit areas). If, say, D were to not do the translation >>for some reason, then the external routes would be unreachable if the >>B-C link went down. >> >> >> > >Type-7 to type-5 translation is done only if type-7 LSA has non-zero >forwarding addresses. So, what extra information does the type-5 LSA >generated by D give to area 0 routers? I would think area 0 routers will >get the same information from type-5 LSA whether it comes from B or D. >As I see, even if D did not do translation, external destinations will >be still reachable even if B-C link went down because area 0 routers >care about connectivity to ASBR (in this case C), which is in no way >dependent upon type-5 LSA generated by D. > >Am I missing something here? > > RFC 3101, and it predecessor RFC 1587, both go to great pain to assure only one ABR translates in order to avoid redundant advertisements. Why wouldn't an ABR not want to take this relatively simple action (clearing the P bit) to avoid a duplicate advertisement? Additionally, you could delay convergence in the situation where the external route becomes unreachably due to the latency of the translating ABR running an SPF and withdrawing the translated type 5 LSA. Hope this helps, Acee > > >>In the case in which we're talking about resetting the P bit, the >>redundant type 5 lsas don't add any new information, since both would >>use the same area to reach the asbr. >> >> > > area 0 area 1 > nssa > A--------B--------C (NSSA translator) > | asbr | > | | > +-----------------+ > Area 0 > >I am drawing the topology above (the case we are interested in for >resetting the P -bit) to visualize it better. > >I see the obvious reason in the above case that database size will >become unnecessarily big because of C translating type-7 into a type-5, >which is the reason mentioned in NSSA RFC that multiple NSSA area border >translators are not recommended. Does the same reason apply to our case? > >Thanks, >Sunil > > > >>Thanks, >>Paul >> >>Sunil Patro wrote: >> >> >>>So, it looks like it is more of an optimization to reset the P bit >>> >>> >in > > >>>type-7 LSA in the case of an originated type-5 LSA also by the ASBR. >>> >>>But Acee, if you look at my example topology below, it still allows >>> >>> >for > > >>>a case where we could still land up with multiple type-5 LSA for the >>>same network even with the ASBR going by the RFC rules of resetting >>> >>> >the > > >>>P bit in type-7 LSA. >>> >>>Also, don't you think the statement of resetting the P bit in the >>> >>> >RFC > > >>>should be "SHOULD" instead of "MUST"? >>> >>>Thanks, >>>Sunil >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>> >>>> >>>Acee >>> >>> >>> >>>>Lindem >>>>Sent: Wednesday, March 08, 2006 6:04 PM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: Re: Question regarding the P bit in type-7 LSA >>>> >>>>Vishwas Manral wrote: >>>> >>>> >>>> >>>> >>>>>Hi Sunil, >>>>> >>>>>Having multiple LSA's for the same destination are not very useful, >>>>> >>>>> >>>>though >>>> >>>> >>>> >>>>>they do not create a problem. >>>>> >>>>>The topology you refer to looks very interesting but may not ever >>>>> >>>>> >be > > >>>that >>> >>> >>> >>>>>way in the real world. >>>>> >>>>> >>>>> >>>>> >>>>Hi Sunil, >>>>I agree with Vishwas. Additionally, since the non-translator >>>> >>>> >ABR/ASBR > > >>>>is the original source of the route, it makes no sense for the >>>>translating ABR to re-advertise it >>>>and will only delay convergence should connectivity to the >>>> >>>> >destination > > >>>>be lost. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>>>Thanks, >>>>>Vishwas >>>>> >>>>>On 3/8/06, Sunil Patro wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Does generating multiple type-5 LSAs for the same destination >>>>>> >>>>>> >>>create >>> >>> >>> >>>>>>problem in any way? The same could happen if multiple ASBRs >>>>>> >>>>>> >generate > > >>>>type-5 >>>> >>>> >>>> >>>>>>LSA for the same network. >>>>>> >>>>>> >>>>>> >>>>>>Coming back to the context again, consider the following network. >>>>>> >>>>>> >>>>>> >>>>>> Area 0 Area 1 (nssa) >>>>>>area 2 (nssa) >>>>>> >>>>>> >>>>>> >>>>>> >>>>A------------------------------B----------------------------------C-- >>>> >>>> >- > > >>>-- >>> >>> >>> >>>>---------------------------------D >>>> >>>> >>>> >>>>>>Area 2's border router D can be either directly connected back to >>>>>> >>>>>> >>>Area 0 >>> >>> >>> >>>>>>again or through a virtual link. >>>>>> >>>>>>In this case, if C generates two type-7 LSAs for a network as an >>>>>> >>>>>> >>>ASBR, >>> >>> >>> >>>>the >>>> >>>> >>>> >>>>>>type-7 will be translated to type-5 through B and D at the same >>>>>> >>>>>> >>>time. >>> >>> >>> >>>>>>So, two type-5 LSA for the same network will end up in area 0. How >>>>>> >>>>>> >>>is >>> >>> >>> >>>>this >>>> >>>> >>>> >>>>>>case handled then? >>>>>> >>>>>> >>>>>> >>>>>>Thanks >>>>>> >>>>>>Sunil >>>>>> >>>>>> >>>>>>------------------------------ >>>>>> >>>>>>*From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf >>>>>> >>>>>> >>>Of >>> >>> >>> >>>>*Vishwas >>>> >>>> >>>> >>>>>>Manral >>>>>>*Sent:* Wednesday, March 08, 2006 12:50 PM >>>>>>*To:* OSPF@PEACH.EASE.LSOFT.COM >>>>>>*Subject:* Re: Question regarding the P bit in type-7 LSA >>>>>> >>>>>> >>>>>> >>>>>>Hi Sunil, >>>>>> >>>>>>Acee may not be able to reply till the evening, so let me give it >>>>>> >>>>>> >a > > >>>try >>> >>> >>> >>>>in >>>> >>>> >>>> >>>>>>the mean while. >>>>>> >>>>>>"If this is the case, the P-bit must be reset in the type-7 NSSA >>>>>> >>>>>> >so > > >>>the >>> >>> >>> >>>>>>type-7 LSA isn't again translated into a type-5 LSA by another >>>>>> >>>>>> >NSSA > > >>>area >>> >>> >>> >>>>>>border router." >>>>>> >>>>>>Isnt the reason embedded in the question you ask? >>>>>> >>>>>>I guess we do not want to originate multiple Type-5 LSA's for the >>>>>> >>>>>> >>>same >>> >>> >>> >>>>>>destination and that is the reason for the P-bit setting. >>>>>> >>>>>>Thanks, >>>>>>Vishwas >>>>>> >>>>>>On 3/8/06, *Sunil Patro* wrote: >>>>>> >>>>>> >>>>>> >>>>>>From section 3.4 of rfc 1587(The OSPF NSSA Option), >>>>> >>>>> >>>>> >>>>>>"If a router is attached to another AS and is also an NSSA area >>>>>> >>>>>> >>>border >>> >>> >>> >>>>>> router, it may originate a both a type-5 and a type-7 LSA for >>>>>> >>>>>> >the > > >>>>>> same network. The type-5 LSA will be flooded to the backbone >>>>>> >>>>>> >>>(and >>> >>> >>> >>>>>> all attached type-5 capable areas) and the type-7 will be >>>>>> >>>>>> >flooded > > >>>>>> into the NSSA. If this is the case, the P-bit must be reset in >>>>>> >>>>>> >>>the >>> >>> >>> >>>>>> type-7 NSSA so the type-7 LSA isn't again translated into a >>>>>> >>>>>> >>>type-5 >>> >>> >>> >>>>>> LSA by another NSSA area border router." >>>>>> >>>>>> >>>>>>Can someone throw some light on why the P bit must be clear in the >>>>>> >>>>>> >>>case >>> >>> >>> >>>>>>when an ASBR originates both a type 7 and type 5 LSA for the same >>>>>>network? >>>>>> >>>>>>Thanks in advance. >>>>>>Sunil >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 14 01:06:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2g5-0007fc-0i for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 01:06:41 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2g4-0005k0-Hw for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 01:06:41 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0003E222@wildebeest.ease.lsoft.com>; Tue, 14 Mar 2006 1:06:40 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=VuOctNARhR/b4bmRp7RLYP0MyKAQmD0RbJMZDZB48908CeV6egGmqJx/8WRKAg9QdJOYzvjH23wWgKEzNajT0dVKrDrOgfdJJf+yTNxBI7gs0T8m8HGVqatpIWOCvX0u; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102101661 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 01:06:39 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Mar 2006 01:06:39 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 13 Mar 2006 22:06:38 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2E66bGv021881 for ; Mon, 13 Mar 2006 22:06:37 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 01:06:37 -0500 Received: from [10.82.240.171] ([10.82.240.171]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 01:06:37 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4415E5D6.6090206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 06:06:37.0218 (UTC) FILETIME=[74045820:01C6472D] Message-ID: <44165D6C.1030903@cisco.com> Date: Tue, 14 Mar 2006 01:06:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4415E5D6.6090206@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22e211536bda974b2dcf811522dc525d Hi Paul, I agree - one point to add inline. Paul Wells wrote: > Hi Sunil, > > Responses inline. > > Sunil Patro wrote: > >> Hi Paul, >> >> Please see inline. >> >> >>> -----Original Message----- >>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> >> >> Paul >> >>> Wells >>> Sent: Friday, March 10, 2006 12:21 PM >>> To: OSPF@PEACH.EASE.LSOFT.COM >>> Subject: Re: Question regarding the P bit in type-7 LSA >>> >>> Hi Sunil, >>> >>> Let me try to redraw your topology with the link between D and the >>> backbone shown to make sure I understand your point: >>> >>> area 0 area 1 area 2 >>> nssa nssa >>> A--------B--------C--------D >>> | asbr | >>> | | >>> +-----------------+ >>> area 0 >>> >>> In this case C generates type-7 lsas with the P bit set and floods >> >> >> them >> >>> to B and D in areas 1 and 2 respectively. B and D will indeed >> >> >> translate >> >>> these into two separate type 5 lsas. However, this is necessary given >>> the topology, as these two lsas are not functionally identical >>> (different transit areas). If, say, D were to not do the translation >>> for some reason, then the external routes would be unreachable if the >>> B-C link went down. >>> >> >> >> Type-7 to type-5 translation is done only if type-7 LSA has non-zero >> forwarding addresses. So, what extra information does the type-5 LSA >> generated by D give to area 0 routers? I would think area 0 routers will >> get the same information from type-5 LSA whether it comes from B or D. >> As I see, even if D did not do translation, external destinations will >> be still reachable even if B-C link went down because area 0 routers >> care about connectivity to ASBR (in this case C), which is in no way >> dependent upon type-5 LSA generated by D. >> >> Am I missing something here? > > > It's true that the type-7s and the translated type-5s will have > forwarding addresses, however they will most likely be different > forwarding addresses. This is probably getting into implementation > details, but I would expect that the type-7 lsa that C originates into > area 1 will have a forwarding address in that area, and similarly for > area 2. The end result is that the two translated type-5s are not > functionally identical. One advertises a path through area 1 while > the other is through area 2, just as if the forwarding address was not > present and the advertising router id of the translator was used. > > Note that the alternate abr behavior of rfc 3509 comes into play here > as well. In fact, the topology we are talking about is presented as > figure 2 in that rfc. For implementations that follow 3509, C won't > be originating summaries between area 1 and 2, so a forwarding address > in the other area won't route through C. For normal ABR behavior (RFC 2328), ASBR C will consider itself an ABR since it is connected to multiple areas and should clear the P bit in the type 7 LSAs originated into NSSAs 1 and 2. Hence, neither ABR B nor ABR D will translate them. Thanks, Acee > >> >> >>> In the case in which we're talking about resetting the P bit, the >>> redundant type 5 lsas don't add any new information, since both would >>> use the same area to reach the asbr. >> >> >> >> area 0 area 1 nssa >> A--------B--------C (NSSA translator) >> | asbr | >> | | >> +-----------------+ >> Area 0 >> >> I am drawing the topology above (the case we are interested in for >> resetting the P -bit) to visualize it better. >> >> I see the obvious reason in the above case that database size will >> become unnecessarily big because of C translating type-7 into a type-5, >> which is the reason mentioned in NSSA RFC that multiple NSSA area border >> translators are not recommended. Does the same reason apply to our case? > > > I'm not sure I understand that last question. In the above case, B is > both an asbr and abr (3509 does not apply). So, the type-5 originated > by B into area 0 is sufficient for backbone routers. For routers in > area 1, the type-7 is sufficient. If C were to translate the type-7 > to a type-5 (with a forwarding address) I don't think it would give > routers in the backbone any additional information about how to reach > the external routes imported by B. > > I think the basic goal remains keeping the lsdb as small as possible > (but no smaller :-), especially since type-5/7 lsas can be quite > numerous. Or did I misunderstand your question? > > Thanks, > Paul > >> >> Thanks, >> Sunil >> >> >>> Thanks, >>> Paul >>> >>> Sunil Patro wrote: >>> >>>> So, it looks like it is more of an optimization to reset the P bit >>> >> >> in >> >>>> type-7 LSA in the case of an originated type-5 LSA also by the ASBR. >>>> >>>> But Acee, if you look at my example topology below, it still allows >>> >> >> for >> >>>> a case where we could still land up with multiple type-5 LSA for the >>>> same network even with the ASBR going by the RFC rules of resetting >>> >> >> the >> >>>> P bit in type-7 LSA. >>>> >>>> Also, don't you think the statement of resetting the P bit in the >>> >> >> RFC >> >>>> should be "SHOULD" instead of "MUST"? >>>> >>>> Thanks, >>>> Sunil >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>> >>>> >>>> Acee >>>> >>>> >>>>> Lindem >>>>> Sent: Wednesday, March 08, 2006 6:04 PM >>>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>>> Subject: Re: Question regarding the P bit in type-7 LSA >>>>> >>>>> Vishwas Manral wrote: >>>>> >>>>> >>>>> >>>>>> Hi Sunil, >>>>>> >>>>>> Having multiple LSA's for the same destination are not very useful, >>>>> >>>>> >>>>> though >>>>> >>>>> >>>>>> they do not create a problem. >>>>>> >>>>>> The topology you refer to looks very interesting but may not ever >>>>> >> >> be >> >>>> that >>>> >>>> >>>>>> way in the real world. >>>>>> >>>>>> >>>>> >>>>> Hi Sunil, >>>>> I agree with Vishwas. Additionally, since the non-translator >>>> >> >> ABR/ASBR >> >>>>> is the original source of the route, it makes no sense for the >>>>> translating ABR to re-advertise it >>>>> and will only delay convergence should connectivity to the >>>> >> >> destination >> >>>>> be lost. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> Vishwas >>>>>> >>>>>> On 3/8/06, Sunil Patro wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Does generating multiple type-5 LSAs for the same destination >>>>>> >>>> >>>> create >>>> >>>> >>>>>>> problem in any way? The same could happen if multiple ASBRs >>>>>> >> >> generate >> >>>>> type-5 >>>>> >>>>> >>>>>>> LSA for the same network. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Coming back to the context again, consider the following network. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Area 0 Area 1 (nssa) >>>>>>> area 2 (nssa) >>>>>>> >>>>>>> >>>>> >>>>> A------------------------------B----------------------------------C-- >>>> >> >> - >> >>>> -- >>>> >>>> >>>>> ---------------------------------D >>>>> >>>>> >>>>>>> >>>>>>> Area 2's border router D can be either directly connected back to >>>>>> >>>> >>>> Area 0 >>>> >>>> >>>>>>> again or through a virtual link. >>>>>>> >>>>>>> In this case, if C generates two type-7 LSAs for a network as an >>>>>> >>>> >>>> ASBR, >>>> >>>> >>>>> the >>>>> >>>>> >>>>>>> type-7 will be translated to type-5 through B and D at the same >>>>>> >>>> >>>> time. >>>> >>>> >>>>>>> So, two type-5 LSA for the same network will end up in area 0. How >>>>>> >>>> >>>> is >>>> >>>> >>>>> this >>>>> >>>>> >>>>>>> case handled then? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Sunil >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> *From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf >>>>>> >>>> >>>> Of >>>> >>>> >>>>> *Vishwas >>>>> >>>>> >>>>>>> Manral >>>>>>> *Sent:* Wednesday, March 08, 2006 12:50 PM >>>>>>> *To:* OSPF@PEACH.EASE.LSOFT.COM >>>>>>> *Subject:* Re: Question regarding the P bit in type-7 LSA >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Sunil, >>>>>>> >>>>>>> Acee may not be able to reply till the evening, so let me give it >>>>>> >> >> a >> >>>> try >>>> >>>> >>>>> in >>>>> >>>>> >>>>>>> the mean while. >>>>>>> >>>>>>> "If this is the case, the P-bit must be reset in the type-7 NSSA >>>>>> >> >> so >> >>>> the >>>> >>>> >>>>>>> type-7 LSA isn't again translated into a type-5 LSA by another >>>>>> >> >> NSSA >> >>>> area >>>> >>>> >>>>>>> border router." >>>>>>> >>>>>>> Isnt the reason embedded in the question you ask? >>>>>>> >>>>>>> I guess we do not want to originate multiple Type-5 LSA's for the >>>>>> >>>> >>>> same >>>> >>>> >>>>>>> destination and that is the reason for the P-bit setting. >>>>>>> >>>>>>> Thanks, >>>>>>> Vishwas >>>>>>> >>>>>>> On 3/8/06, *Sunil Patro* wrote: >>>>>>> >>>>>> >>>>>>> From section 3.4 of rfc 1587(The OSPF NSSA Option), >>>>>> >>>>>> >>>>>> >>>>>>> "If a router is attached to another AS and is also an NSSA area >>>>>> >>>> >>>> border >>>> >>>> >>>>>>> router, it may originate a both a type-5 and a type-7 LSA for >>>>>> >> >> the >> >>>>>>> same network. The type-5 LSA will be flooded to the backbone >>>>>> >>>> >>>> (and >>>> >>>> >>>>>>> all attached type-5 capable areas) and the type-7 will be >>>>>> >> >> flooded >> >>>>>>> into the NSSA. If this is the case, the P-bit must be reset in >>>>>> >>>> >>>> the >>>> >>>> >>>>>>> type-7 NSSA so the type-7 LSA isn't again translated into a >>>>>> >>>> >>>> type-5 >>>> >>>> >>>>>>> LSA by another NSSA area border router." >>>>>>> >>>>>>> >>>>>>> Can someone throw some light on why the P bit must be clear in the >>>>>> >>>> >>>> case >>>> >>>> >>>>>>> when an ASBR originates both a type 7 and type 5 LSA for the same >>>>>>> network? >>>>>>> >>>>>>> Thanks in advance. >>>>>>> Sunil >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 14 02:24:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3tD-0002PL-5X for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 02:24:19 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ3tB-0008DB-Kt for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 02:24:19 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.0003E323@wildebeest.ease.lsoft.com>; Tue, 14 Mar 2006 2:24:17 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=C13dTRuseUF2w3F06Qsy0mQ8Vfvv6DBbifXHtv7fEpUkUK52GNmoJwaqxfHHFMVksnFNXapL/mhaTJthm6HMimnbkE8bCiiZixFWf0gmGf2N4xG9LjriTC45fdkZIU3C; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102106855 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 02:24:16 -0500 Received: from 171.71.176.117 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Mar 2006 02:24:16 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 13 Mar 2006 23:24:15 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2E7OEw1013914 for ; Mon, 13 Mar 2006 23:24:15 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 02:24:13 -0500 Received: from [10.82.240.171] ([10.82.240.171]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 02:24:13 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4415E5D6.6090206@cisco.com> <44165D6C.1030903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 07:24:13.0358 (UTC) FILETIME=[4B4AECE0:01C64738] Message-ID: <44166F9B.1000309@cisco.com> Date: Tue, 14 Mar 2006 02:24:11 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <44165D6C.1030903@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c Acee Lindem wrote: > Hi Paul, > > I agree - one point to add inline. > > Paul Wells wrote: > >> Hi Sunil, >> >> Responses inline. >> >> Sunil Patro wrote: >> >>> Hi Paul, >>> >>> Please see inline. >>> >>> >>>> -----Original Message----- >>>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>> >>> >>> >>> Paul >>> >>>> Wells >>>> Sent: Friday, March 10, 2006 12:21 PM >>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>> Subject: Re: Question regarding the P bit in type-7 LSA >>>> >>>> Hi Sunil, >>>> >>>> Let me try to redraw your topology with the link between D and the >>>> backbone shown to make sure I understand your point: >>>> >>>> area 0 area 1 area 2 >>>> nssa nssa >>>> A--------B--------C--------D >>>> | asbr | >>>> | | >>>> +-----------------+ >>>> area 0 >>>> >>>> In this case C generates type-7 lsas with the P bit set and floods >>> >>> >>> >>> them >>> >>>> to B and D in areas 1 and 2 respectively. B and D will indeed >>> >>> >>> >>> translate >>> >>>> these into two separate type 5 lsas. However, this is necessary given >>>> the topology, as these two lsas are not functionally identical >>>> (different transit areas). If, say, D were to not do the translation >>>> for some reason, then the external routes would be unreachable if the >>>> B-C link went down. >>>> >>> >>> >>> Type-7 to type-5 translation is done only if type-7 LSA has non-zero >>> forwarding addresses. So, what extra information does the type-5 LSA >>> generated by D give to area 0 routers? I would think area 0 routers >>> will >>> get the same information from type-5 LSA whether it comes from B or D. >>> As I see, even if D did not do translation, external destinations will >>> be still reachable even if B-C link went down because area 0 routers >>> care about connectivity to ASBR (in this case C), which is in no way >>> dependent upon type-5 LSA generated by D. >>> >>> Am I missing something here? >> >> >> >> It's true that the type-7s and the translated type-5s will have >> forwarding addresses, however they will most likely be different >> forwarding addresses. This is probably getting into implementation >> details, but I would expect that the type-7 lsa that C originates >> into area 1 will have a forwarding address in that area, and >> similarly for area 2. The end result is that the two translated >> type-5s are not functionally identical. One advertises a path >> through area 1 while the other is through area 2, just as if the >> forwarding address was not present and the advertising router id of >> the translator was used. >> >> Note that the alternate abr behavior of rfc 3509 comes into play here >> as well. In fact, the topology we are talking about is presented as >> figure 2 in that rfc. For implementations that follow 3509, C won't >> be originating summaries between area 1 and 2, so a forwarding >> address in the other area won't route through C. > > > For normal ABR behavior (RFC 2328), ASBR C will consider itself an ABR > since > it is connected to multiple areas and should clear the P bit in the > type 7 LSAs > originated into NSSAs 1 and 2. Hence, neither ABR B nor ABR D will > translate > them. I checked RFC 3101 and the criteria for mandatory clearing of the P bit is dependent on whether or not a type 5 is originated as well (see excerpt below) So, I was incorrect in saying that ASBR C would clear the P bit :^) When an NSSA border router originates both a Type-5 LSA and a Type-7 LSA for the same network, then the P-bit must be clear in the Type-7 LSA so that it isn't translated into a Type-5 LSA by another NSSA border router. If the border router only originates a Type-7 LSA, it may set the P-bit so that the network may be aggregated/propagated during Type-7 translation. If an NSSA's border router originates a Type-5 LSA with a forwarding address from the NSSA, it should also originate a Type-7 LSA into the NSSA. I agree that originating type 7 LSAs into both areas is the correct behavior and that the respective forwarding addresses will be different. Keep in mind that one or neither of the NSSAs will have an intra-area route to the external route's next-hop address. When the next-hop address doesn't correspond to an NSSA intra-area route, the forwarding address will be selected as specified in section 2.3 of RFC 3101 (see excerpt below). When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router's internal addresses (provided internal addressing is supported). If internal addresses are not available, preference should be given to the router's active OSPF stub network addresses. These choices avoid the possible extra hop that may happen when a transit network's address is used. When the interface whose IP address is the LSA's forwarding address transitions to a Down state (see [OSPF] Section 9.3), the router must select a new forwarding address for the LSA and then re- originate it. If one is not available the LSA should be flushed. Thanks, Acee > > Thanks, > Acee > >> >>> >>> >>>> In the case in which we're talking about resetting the P bit, the >>>> redundant type 5 lsas don't add any new information, since both would >>>> use the same area to reach the asbr. >>> >>> >>> >>> >>> area 0 area 1 nssa >>> A--------B--------C (NSSA translator) >>> | asbr | >>> | | >>> +-----------------+ >>> Area 0 >>> >>> I am drawing the topology above (the case we are interested in for >>> resetting the P -bit) to visualize it better. >>> >>> I see the obvious reason in the above case that database size will >>> become unnecessarily big because of C translating type-7 into a type-5, >>> which is the reason mentioned in NSSA RFC that multiple NSSA area >>> border >>> translators are not recommended. Does the same reason apply to our >>> case? >> >> >> >> I'm not sure I understand that last question. In the above case, B >> is both an asbr and abr (3509 does not apply). So, the type-5 >> originated by B into area 0 is sufficient for backbone routers. For >> routers in area 1, the type-7 is sufficient. If C were to translate >> the type-7 to a type-5 (with a forwarding address) I don't think it >> would give routers in the backbone any additional information about >> how to reach the external routes imported by B. >> >> I think the basic goal remains keeping the lsdb as small as possible >> (but no smaller :-), especially since type-5/7 lsas can be quite >> numerous. Or did I misunderstand your question? >> >> Thanks, >> Paul >> >>> >>> Thanks, >>> Sunil >>> >>> >>>> Thanks, >>>> Paul >>>> >>>> Sunil Patro wrote: >>>> >>>>> So, it looks like it is more of an optimization to reset the P bit >>>> >>>> >>> >>> in >>> >>>>> type-7 LSA in the case of an originated type-5 LSA also by the ASBR. >>>>> >>>>> But Acee, if you look at my example topology below, it still allows >>>> >>>> >>> >>> for >>> >>>>> a case where we could still land up with multiple type-5 LSA for the >>>>> same network even with the ASBR going by the RFC rules of resetting >>>> >>>> >>> >>> the >>> >>>>> P bit in type-7 LSA. >>>>> >>>>> Also, don't you think the statement of resetting the P bit in the >>>> >>>> >>> >>> RFC >>> >>>>> should be "SHOULD" instead of "MUST"? >>>>> >>>>> Thanks, >>>>> Sunil >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>>> >>>>> >>>>> >>>>> Acee >>>>> >>>>> >>>>>> Lindem >>>>>> Sent: Wednesday, March 08, 2006 6:04 PM >>>>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>>>> Subject: Re: Question regarding the P bit in type-7 LSA >>>>>> >>>>>> Vishwas Manral wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi Sunil, >>>>>>> >>>>>>> Having multiple LSA's for the same destination are not very useful, >>>>>> >>>>>> >>>>>> >>>>>> though >>>>>> >>>>>> >>>>>>> they do not create a problem. >>>>>>> >>>>>>> The topology you refer to looks very interesting but may not ever >>>>>> >>>>>> >>> >>> be >>> >>>>> that >>>>> >>>>> >>>>>>> way in the real world. >>>>>>> >>>>>>> >>>>>> >>>>>> Hi Sunil, >>>>>> I agree with Vishwas. Additionally, since the non-translator >>>>> >>>>> >>> >>> ABR/ASBR >>> >>>>>> is the original source of the route, it makes no sense for the >>>>>> translating ABR to re-advertise it >>>>>> and will only delay convergence should connectivity to the >>>>> >>>>> >>> >>> destination >>> >>>>>> be lost. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Vishwas >>>>>>> >>>>>>> On 3/8/06, Sunil Patro wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Does generating multiple type-5 LSAs for the same destination >>>>>>> >>>>>>> >>>>> >>>>> create >>>>> >>>>> >>>>>>>> problem in any way? The same could happen if multiple ASBRs >>>>>>> >>>>>>> >>> >>> generate >>> >>>>>> type-5 >>>>>> >>>>>> >>>>>>>> LSA for the same network. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Coming back to the context again, consider the following network. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Area 0 Area 1 (nssa) >>>>>>>> area 2 (nssa) >>>>>>>> >>>>>>>> >>>>>> >>>>>> A------------------------------B----------------------------------C-- >>>>>> >>>>> >>>>> >>> >>> - >>> >>>>> -- >>>>> >>>>> >>>>>> ---------------------------------D >>>>>> >>>>>> >>>>>>>> >>>>>>>> Area 2's border router D can be either directly connected back to >>>>>>> >>>>>>> >>>>> >>>>> Area 0 >>>>> >>>>> >>>>>>>> again or through a virtual link. >>>>>>>> >>>>>>>> In this case, if C generates two type-7 LSAs for a network as an >>>>>>> >>>>>>> >>>>> >>>>> ASBR, >>>>> >>>>> >>>>>> the >>>>>> >>>>>> >>>>>>>> type-7 will be translated to type-5 through B and D at the same >>>>>>> >>>>>>> >>>>> >>>>> time. >>>>> >>>>> >>>>>>>> So, two type-5 LSA for the same network will end up in area 0. How >>>>>>> >>>>>>> >>>>> >>>>> is >>>>> >>>>> >>>>>> this >>>>>> >>>>>> >>>>>>>> case handled then? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Sunil >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> *From:* Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] *On Behalf >>>>>>> >>>>>>> >>>>> >>>>> Of >>>>> >>>>> >>>>>> *Vishwas >>>>>> >>>>>> >>>>>>>> Manral >>>>>>>> *Sent:* Wednesday, March 08, 2006 12:50 PM >>>>>>>> *To:* OSPF@PEACH.EASE.LSOFT.COM >>>>>>>> *Subject:* Re: Question regarding the P bit in type-7 LSA >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Sunil, >>>>>>>> >>>>>>>> Acee may not be able to reply till the evening, so let me give it >>>>>>> >>>>>>> >>> >>> a >>> >>>>> try >>>>> >>>>> >>>>>> in >>>>>> >>>>>> >>>>>>>> the mean while. >>>>>>>> >>>>>>>> "If this is the case, the P-bit must be reset in the type-7 NSSA >>>>>>> >>>>>>> >>> >>> so >>> >>>>> the >>>>> >>>>> >>>>>>>> type-7 LSA isn't again translated into a type-5 LSA by another >>>>>>> >>>>>>> >>> >>> NSSA >>> >>>>> area >>>>> >>>>> >>>>>>>> border router." >>>>>>>> >>>>>>>> Isnt the reason embedded in the question you ask? >>>>>>>> >>>>>>>> I guess we do not want to originate multiple Type-5 LSA's for the >>>>>>> >>>>>>> >>>>> >>>>> same >>>>> >>>>> >>>>>>>> destination and that is the reason for the P-bit setting. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vishwas >>>>>>>> >>>>>>>> On 3/8/06, *Sunil Patro* wrote: >>>>>>>> >>>>>>> >>>>>>>> From section 3.4 of rfc 1587(The OSPF NSSA Option), >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> "If a router is attached to another AS and is also an NSSA area >>>>>>> >>>>>>> >>>>> >>>>> border >>>>> >>>>> >>>>>>>> router, it may originate a both a type-5 and a type-7 LSA for >>>>>>> >>>>>>> >>> >>> the >>> >>>>>>>> same network. The type-5 LSA will be flooded to the backbone >>>>>>> >>>>>>> >>>>> >>>>> (and >>>>> >>>>> >>>>>>>> all attached type-5 capable areas) and the type-7 will be >>>>>>> >>>>>>> >>> >>> flooded >>> >>>>>>>> into the NSSA. If this is the case, the P-bit must be reset in >>>>>>> >>>>>>> >>>>> >>>>> the >>>>> >>>>> >>>>>>>> type-7 NSSA so the type-7 LSA isn't again translated into a >>>>>>> >>>>>>> >>>>> >>>>> type-5 >>>>> >>>>> >>>>>>>> LSA by another NSSA area border router." >>>>>>>> >>>>>>>> >>>>>>>> Can someone throw some light on why the P bit must be clear in the >>>>>>> >>>>>>> >>>>> >>>>> case >>>>> >>>>> >>>>>>>> when an ASBR originates both a type 7 and type 5 LSA for the same >>>>>>>> network? >>>>>>>> >>>>>>>> Thanks in advance. >>>>>>>> Sunil >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >> > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 14 12:02:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCuJ-0005ir-QE for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 12:02:03 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJCuJ-0007X5-IW for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 12:02:03 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.0003E4CC@wildebeest.ease.lsoft.com>; Tue, 14 Mar 2006 12:02:02 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-VMS-To:X-VMS-Cc:MIME-version:Content-type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=JiECpu0zx493loMWZFNjF55f/ByPEMx4yNvd3ZYvi/kzdVgDOQikBVulWXVZrjJZx0ByNc+pvBFxy7xYm+5QSag1849dNTYTRMN3vPCzk6ublPrHOyUOTOJY+uKXD47r; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102166220 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 12:02:02 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Mar 2006 12:02:01 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01M01FIR19K0000TQD@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 09:00:12 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01M01FIR1AIA000TQD@omega7.wr.usgs.gov> Date: Tue, 14 Mar 2006 09:00:12 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Regarding the initial question >Can someone throw some light on why the P bit must be clear in >the case when an ASBR originates both a type 7 and type 5 LSA >for the same network? here is a minor thought. When a Type 5 LSA is originated the forwarding address is set based on the discussion in RFC 2328 Section 12.4.4.1. This need not (and should not) be an address from a directly attached NSSA and could even be 0.0.0.0. As Acee and others have pointed out, a Type 7 LSA with the P-bit set must have a non-zero forwarding address from the NSSA. If one attempted to advertise such beasts simultaneously wouldn't the translation process of RFC 3101 Section 3.2 Step (2) ...then a Type-5 LSA should be generated if there is currently no Type-5 LSA originating from this router corresponding to the Type-7 LSA's network, or there is an existing Type-5 LSA and either it corresponds to a local OSPF external source whose path type and metric is less preferred (see Section 2.5 step (6), parts (b) and (d)), or it doesn't and the Type-5 LSA's path type or cost(s) have changed (See Section 2.5 step (5)) or the forwarding address no longer maps to a translatable Type-7 LSA. cause these two originations to thrash? Keep in mind that every NSSA ABR is a potential translator. With the P-bit always clear, this is not an implementation issue. I would like to see a minor change in Type 5 originations, namely that a non-zero forwarding address must be computed from the OSPF domain's "transit" topology. It should never be chosen from a stub area or NSSA. If the true forwarding address is in a directly attached stub area or NSSA, the Type 5 LSA's forwarding address is simply set to 0.0.0.0; The only exception to this rule happens during Type-7 translation. This would eliminate the requirement for the last line in When an NSSA border router originates both a Type-5 LSA and a Type-7 LSA for the same network, then the P-bit must be clear in the Type-7 LSA so that it isn't translated into a Type-5 LSA by another NSSA border router. If the border router only originates a Type-7 LSA, it may set the P-bit so that the network may be aggregated/propagated during Type-7 translation. If an NSSA's border router originates a Type-5 LSA with a forwarding address from the NSSA, it should also originate a Type-7 LSA into the NSSA. If one really wants this behavior they need only set the P-bit and let translation originate the Type 5 LSA. Type 5 LSAs with a forwarding address from a directly attached NSSA are never installed (See the last paragraph of RFC 3101 Section 2.3 Step (3)) on NSSA border routers. Thus they create the potential for black holes. I think this is a loose point in the base OSPF spec. While the NSSA spec handles it, given all of the available OSPF implementation knobs for filtering external advertisements, careful implementation is required. Since it is not necessary for feature, why have it? Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 14 12:47:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDcg-0003tY-RY for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 12:47:54 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDcg-0008TM-E5 for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 12:47:54 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.0003E50E@wildebeest.ease.lsoft.com>; Tue, 14 Mar 2006 12:47:53 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=JGRA3TuVaNRmYI+KbG/hbDL6XqhQy1+tndFomHLfxOjXZU6U+gwcEq1crVSUZ8qzWHXl44Nw1NCgVaCppc/+6a3ENEMBNrnWDL1WApfUjSe8EBEXpGcFN/XT0PZhzFlA; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102169694 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 12:47:53 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Mar 2006 12:47:52 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2006 09:47:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,191,1139212800"; d="scan'208"; a="23572327:sNHT37416356" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2EHlpVa016689 for ; Tue, 14 Mar 2006 12:47:51 -0500 (EST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 12:46:55 -0500 Received: from [128.107.163.203] ([128.107.163.203]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 12:46:54 -0500 User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <0551D846F0819D4F9BD6EF2E7D18D59B807FC8@ussj1wms2> <4415D8D2.7030106@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 17:46:54.0987 (UTC) FILETIME=[488F15B0:01C6478F] Message-ID: <4417018E.8000408@cisco.com> Date: Tue, 14 Mar 2006 09:46:54 -0800 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Re: OAPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4415D8D2.7030106@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Hi Acee, Opinion inline. Acee Lindem wrote: > Hi Manoj, > > Goyal, Manoj wrote: > >> Hi Acee, >> I feel a description could be added to make it clear that: >> >> - the link LSAs are only required for broadcast and NBMA links. >> - for p2p links they are not required (or optional) >> - and if a link LSA is generated for a link that is p2p, >> then it should not include any prefixes as they are already >> available in intra-area-prefix LSAs. >> >> Even for the implementation purpose, during route calculation, >> getting the link-local address on a p2p link though its neighbor >> is quicker/easier then parsing the link-lsa of the neighbor >> to get the link-local address from there. >> >> > I'd certainly agree here - also you don't really need the next-hop > address on a p2p > link. However, I'd hate to render an existing RFC 2740 implementation > incompatible > without at least a knob. I do not, however, see much value to including > the global > prefixes in the link LSA for p2p or p2mp links. Any other opinions here? There are two separate issues here. The first one discussed was whether global prefixes are really needed in the link lsa for p2p links. Offhand I can't think of a case where they are, but I'm not sure I see a big advantage in having a special case to omit them. The second question was whether link lsas and their link-local address are required for p2p links at all. Here I would argue for retaining the current specification that requires them. While an implementation may have a link-local address for it's neighbor in the neighbor structure, I think that there is significant architectural value in keeping the link state database self-sufficient for computing routes. For one thing, there may be cases where the lsdb is being used by applications other than routing and the neighbor structure may not available. Also, as you point out, there may be existing implementations based on 2740 that depend on it. I'm unconvinced that the very minor savings of memory and cpu gained by omitting the link lsas are worth it. Thanks, Paul > > Thanks, > Acee > >> Thanks, >> Manoj >> >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >> Lindem >> Sent: Thursday, March 09, 2006 4:44 PM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Re: OAPFv3: what is the use of prefixes in Link LSA >> >> Goyal, Manoj wrote: >> >> >> >>> I think I asked the first question in a wrong way, sure that >>> the link LSAs are used by the DR to construct the IAP-LSA for the >>> broadcast network. >>> But what is the use of the link LSAs having prefixes for >>> P2P links as all the prefixes are present in the router's >>> IAP LSAs already?? Practically most links are P2P. >>> >>> >>> >> >> Hi Manoj, >> >> In the RFC 2370 update draft, I added text explicitly stating that >> link LSAs are not >> needed for virtual links. I considered saying they MAY be omitted >> on p2p links as well but was worried that conceivably an >> implementation could >> use link LSAs exclusively for next-hop computation (they are needed >> for next-hop >> computation on NBMA links). Are there other opinions on this? >> >> Thanks, >> Acee >> >> >> >>> Manoj >>> >>> -----Original Message----- >>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Paul >>> Wells >>> Sent: Wednesday, March 08, 2006 6:01 PM >>> To: OSPF@PEACH.EASE.LSOFT.COM >>> Subject: Re: OAPFv3: what is the use of prefixes in Link LSA >>> >>> Hi Manoj, >>> >>> Goyal, Manoj wrote: >>> >>> >>> >>> >>>> HI, >>>> >>>> In ospfv3 the intra-area-prefix LSAs have all the prefixes and routing >>>> >>>> >>> >>> table >>> >>> >>> >>> >>>> should be calculated using them. Then what is really the use of having >>>> >>>> the prefixes of the link in its link-LSA. >>>> >>>> >>> >>> For broadcast and nbma links, the prefixes in the link lsas are used by >>> >> >> >> >> >>> the DR to construct the intra-area prefix lsa associated with the >>> network lsa. >>> >>> >>> >>> >>> >>>> Is there a case where the router will not include some prefixes in >>>> intra-area-prefix LSA >>>> >>>> but advertise in the link-LSA? I don't see any such case. >>>> >>>> >>> >>> Prefixes for broadcast/nbma transit links are advertised by the DR on >>> behalf of the attached routers, and not by the non-DR routers >>> themselves. But if you are asking if some of the prefixes won't appear >>> >> >> >> >> >>> in _any_ intra-area prefix lsa, then no, I don't think so. >>> >>> Regards, >>> Paul >>> >>> >>> >>> >>> >>>> Thanks, >>>> >>>> Manoj >>>> >>>> >>> >>> ============================================================ >>> The information contained in this message may be privileged >>> and confidential and protected from disclosure. If the reader >>> of this message is not the intended recipient, or an employee >>> or agent responsible for delivering this message to the >>> intended recipient, you are hereby notified that any reproduction, >>> dissemination or distribution of this communication is strictly >>> prohibited. If you have received this communication in error, >>> please notify us immediately by replying to the message and >>> deleting it from your computer. Thank you. Tellabs >>> ============================================================ >>> >>> >>> >>> >> >> ============================================================ >> The information contained in this message may be privileged >> and confidential and protected from disclosure. If the reader >> of this message is not the intended recipient, or an employee >> or agent responsible for delivering this message to the >> intended recipient, you are hereby notified that any reproduction, >> dissemination or distribution of this communication is strictly >> prohibited. If you have received this communication in error, >> please notify us immediately by replying to the message and >> deleting it from your computer. Thank you. Tellabs >> ============================================================ >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 14 14:37:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFKU-0003Y1-9N for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 14:37:14 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJFKT-00035I-PP for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 14:37:14 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.0003E568@wildebeest.ease.lsoft.com>; Tue, 14 Mar 2006 14:37:12 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=MQfpAMnz+0WToeQO74RMJXQwGjr7uKQzf9ftKdrXGeowl1pmmvjiNW++IbI5p/bNOQr6GofLao8glBeaUquw0Gd1WWr7DCSDHm7HucvBgowAgnq+3TL6pfaRCl4DneTt; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102176978 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 14:37:12 -0500 Received: from 171.71.176.117 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Mar 2006 14:37:11 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 14 Mar 2006 11:37:11 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2EJb97X013696 for ; Tue, 14 Mar 2006 11:37:11 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 11:37:09 -0800 Received: from [128.107.176.113] ([128.107.176.113]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 11:37:09 -0800 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <0551D846F0819D4F9BD6EF2E7D18D59B807FC8@ussj1wms2> <4415D8D2.7030106@cisco.com> <4417018E.8000408@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 19:37:09.0508 (UTC) FILETIME=[AF1EE440:01C6479E] Message-ID: <44171B65.2070109@cisco.com> Date: Tue, 14 Mar 2006 14:37:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OAPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4417018E.8000408@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Hi Paul, I tend to agree - the advantage is marginal. The only reason I could see for putting a single global prefix on a P2P link would be for the Network Management monitoring applications that ping every interface in the network. Thanks, Acee Paul Wells wrote: > Hi Acee, > > Opinion inline. > > Acee Lindem wrote: > >> Hi Manoj, >> >> Goyal, Manoj wrote: >> >>> Hi Acee, >>> I feel a description could be added to make it clear that: >>> >>> - the link LSAs are only required for broadcast and NBMA links. >>> - for p2p links they are not required (or optional) >>> - and if a link LSA is generated for a link that is p2p, >>> then it should not include any prefixes as they are already >>> available in intra-area-prefix LSAs. >>> >>> Even for the implementation purpose, during route calculation, >>> getting the link-local address on a p2p link though its neighbor >>> is quicker/easier then parsing the link-lsa of the neighbor >>> to get the link-local address from there. >>> >>> >> I'd certainly agree here - also you don't really need the next-hop >> address on a p2p >> link. However, I'd hate to render an existing RFC 2740 implementation >> incompatible >> without at least a knob. I do not, however, see much value to >> including the global >> prefixes in the link LSA for p2p or p2mp links. Any other opinions here? > > > There are two separate issues here. The first one discussed was > whether global prefixes are really needed in the link lsa for p2p > links. Offhand I can't think of a case where they are, but I'm not > sure I see a big advantage in having a special case to omit them. > > The second question was whether link lsas and their link-local address > are required for p2p links at all. Here I would argue for retaining > the current specification that requires them. > > While an implementation may have a link-local address for it's > neighbor in the neighbor structure, I think that there is significant > architectural value in keeping the link state database self-sufficient > for computing routes. For one thing, there may be cases where the > lsdb is being used by applications other than routing and the neighbor > structure may not available. Also, as you point out, there may be > existing implementations based on 2740 that depend on it. I'm > unconvinced that the very minor savings of memory and cpu gained by > omitting the link lsas are worth it. > > Thanks, > Paul > >> >> Thanks, >> Acee >> >>> Thanks, >>> Manoj >>> >>> -----Original Message----- >>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >>> Lindem >>> Sent: Thursday, March 09, 2006 4:44 PM >>> To: OSPF@PEACH.EASE.LSOFT.COM >>> Subject: Re: OAPFv3: what is the use of prefixes in Link LSA >>> >>> Goyal, Manoj wrote: >>> >>> >>> >>>> I think I asked the first question in a wrong way, sure that >>>> the link LSAs are used by the DR to construct the IAP-LSA for the >>>> broadcast network. >>>> But what is the use of the link LSAs having prefixes for >>>> P2P links as all the prefixes are present in the router's >>>> IAP LSAs already?? Practically most links are P2P. >>>> >>>> >>>> >>> >>> >>> Hi Manoj, >>> >>> In the RFC 2370 update draft, I added text explicitly stating that >>> link LSAs are not >>> needed for virtual links. I considered saying they MAY be omitted >>> on p2p links as well but was worried that conceivably an >>> implementation could >>> use link LSAs exclusively for next-hop computation (they are needed >>> for next-hop >>> computation on NBMA links). Are there other opinions on this? >>> >>> Thanks, >>> Acee >>> >>> >>> >>>> Manoj >>>> >>>> -----Original Message----- >>>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>> Paul >>>> Wells >>>> Sent: Wednesday, March 08, 2006 6:01 PM >>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>> Subject: Re: OAPFv3: what is the use of prefixes in Link LSA >>>> >>>> Hi Manoj, >>>> >>>> Goyal, Manoj wrote: >>>> >>>> >>>> >>>> >>>>> HI, >>>>> >>>>> In ospfv3 the intra-area-prefix LSAs have all the prefixes and >>>>> routing >>>>> >>>>> >>>> >>>> >>>> table >>>> >>>> >>>> >>>> >>>>> should be calculated using them. Then what is really the use of >>>>> having >>>>> >>>>> the prefixes of the link in its link-LSA. >>>>> >>>>> >>>> >>>> >>>> For broadcast and nbma links, the prefixes in the link lsas are >>>> used by >>>> >>> >>> >>> >>> >>> >>>> the DR to construct the intra-area prefix lsa associated with the >>>> network lsa. >>>> >>>> >>>> >>>> >>>> >>>>> Is there a case where the router will not include some prefixes in >>>>> intra-area-prefix LSA >>>>> >>>>> but advertise in the link-LSA? I don't see any such case. >>>>> >>>>> >>>> >>>> >>>> Prefixes for broadcast/nbma transit links are advertised by the DR >>>> on behalf of the attached routers, and not by the non-DR routers >>>> themselves. But if you are asking if some of the prefixes won't >>>> appear >>>> >>> >>> >>> >>> >>> >>>> in _any_ intra-area prefix lsa, then no, I don't think so. >>>> >>>> Regards, >>>> Paul >>>> >>>> >>>> >>>> >>>> >>>>> Thanks, >>>>> >>>>> Manoj >>>>> >>>>> >>>> >>>> >>>> ============================================================ >>>> The information contained in this message may be privileged >>>> and confidential and protected from disclosure. If the reader >>>> of this message is not the intended recipient, or an employee >>>> or agent responsible for delivering this message to the >>>> intended recipient, you are hereby notified that any reproduction, >>>> dissemination or distribution of this communication is strictly >>>> prohibited. If you have received this communication in error, >>>> please notify us immediately by replying to the message and >>>> deleting it from your computer. Thank you. Tellabs >>>> ============================================================ >>>> >>>> >>>> >>>> >>> >>> >>> ============================================================ >>> The information contained in this message may be privileged >>> and confidential and protected from disclosure. If the reader >>> of this message is not the intended recipient, or an employee >>> or agent responsible for delivering this message to the >>> intended recipient, you are hereby notified that any reproduction, >>> dissemination or distribution of this communication is strictly >>> prohibited. If you have received this communication in error, >>> please notify us immediately by replying to the message and >>> deleting it from your computer. Thank you. Tellabs >>> ============================================================ >>> >>> >>> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 14 14:45:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFSv-00086r-J0 for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 14:45:57 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJFSv-0003Ca-7c for ospf-archive@LISTS.IETF.ORG; Tue, 14 Mar 2006 14:45:57 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.0003E45D@wildebeest.ease.lsoft.com>; Tue, 14 Mar 2006 14:45:56 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-SBRS:X-IronPort-AV:X-MimeOLE:Content-class:MIME-Version:X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:X-OriginalArrivalTime:Content-Transfer-Encoding:Content-Type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=LuV/Y4Z2YdiwEFp1WkNoZ/tl24bj0SMREx0u7wxGQo9z8CV4fMe62t3t2uY1flZW2LhID6WnH8qXEwhQjJJ3Byo9ANPIz/COwMY2pl7yITlbINogOPO7xyafOjnyvolS; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102177552 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Mar 2006 14:45:56 -0500 Received: from 204.154.129.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Mar 2006 14:45:56 -0500 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 14 Mar 2006 19:45:56 +0000 X-SBRS: None X-IronPort-AV: i="4.02,191,1139184000"; d="scan'208"; a="47291845:sNHT211521008" Received: from ussj1wms2.tellabs-west.tellabsinc.net ([172.25.6.30]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Mar 2006 13:45:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPFv3: what is the use of prefixes in Link LSA Thread-Index: AcZHnrf8bLNd/GmpR7SUixT1ZuXOrwAAIm+A X-OriginalArrivalTime: 14 Mar 2006 19:45:56.0074 (UTC) FILETIME=[E8FA7CA0:01C6479F] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Message-ID: <0551D846F0819D4F9BD6EF2E7D18D59B88EB82@ussj1wms2> Date: Tue, 14 Mar 2006 11:45:54 -0800 Reply-To: Mailing List Sender: Mailing List From: "Goyal, Manoj" Subject: Re: OSPFv3: what is the use of prefixes in Link LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 That makes sense to keep the link LSA with one optional Global prefix and omit the rest of the prefixes for p2p. These link LSAs may also play a role in Traffic-Engineering for OSPFv3 or other applications. Thanks, Manoj -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Tuesday, March 14, 2006 11:37 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OAPFv3: what is the use of prefixes in Link LSA Hi Paul, I tend to agree - the advantage is marginal. The only reason I could see for putting a single global prefix on a P2P link would be for the Network Management monitoring applications that ping every interface in the network. Thanks, Acee Paul Wells wrote: > Hi Acee, > > Opinion inline. > > Acee Lindem wrote: > >> Hi Manoj, >> >> Goyal, Manoj wrote: >> >>> Hi Acee, >>> I feel a description could be added to make it clear that: >>> >>> - the link LSAs are only required for broadcast and NBMA links. >>> - for p2p links they are not required (or optional) >>> - and if a link LSA is generated for a link that is p2p, >>> then it should not include any prefixes as they are already >>> available in intra-area-prefix LSAs. >>> >>> Even for the implementation purpose, during route calculation, >>> getting the link-local address on a p2p link though its neighbor >>> is quicker/easier then parsing the link-lsa of the neighbor >>> to get the link-local address from there. >>> =20 >>> >> I'd certainly agree here - also you don't really need the next-hop=20 >> address on a p2p >> link. However, I'd hate to render an existing RFC 2740 implementation >> incompatible >> without at least a knob. I do not, however, see much value to=20 >> including the global >> prefixes in the link LSA for p2p or p2mp links. Any other opinions here? > > > There are two separate issues here. The first one discussed was=20 > whether global prefixes are really needed in the link lsa for p2p=20 > links. Offhand I can't think of a case where they are, but I'm not=20 > sure I see a big advantage in having a special case to omit them. > > The second question was whether link lsas and their link-local address > are required for p2p links at all. Here I would argue for retaining=20 > the current specification that requires them. > > While an implementation may have a link-local address for it's=20 > neighbor in the neighbor structure, I think that there is significant=20 > architectural value in keeping the link state database self-sufficient > for computing routes. For one thing, there may be cases where the=20 > lsdb is being used by applications other than routing and the neighbor > structure may not available. Also, as you point out, there may be=20 > existing implementations based on 2740 that depend on it. I'm=20 > unconvinced that the very minor savings of memory and cpu gained by=20 > omitting the link lsas are worth it. > > Thanks, > Paul > >> >> Thanks, >> Acee >> >>> Thanks, >>> Manoj >>> >>> -----Original Message----- >>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >>> Lindem >>> Sent: Thursday, March 09, 2006 4:44 PM >>> To: OSPF@PEACH.EASE.LSOFT.COM >>> Subject: Re: OAPFv3: what is the use of prefixes in Link LSA >>> >>> Goyal, Manoj wrote: >>> >>> =20 >>> >>>> I think I asked the first question in a wrong way, sure that >>>> the link LSAs are used by the DR to construct the IAP-LSA for the >>>> broadcast network. >>>> But what is the use of the link LSAs having prefixes for >>>> P2P links as all the prefixes are present in the router's >>>> IAP LSAs already?? Practically most links are P2P. >>>> >>>> >>>> =20 >>> >>> >>> Hi Manoj, >>> >>> In the RFC 2370 update draft, I added text explicitly stating that=20 >>> link LSAs are not >>> needed for virtual links. I considered saying they MAY be omitted >>> on p2p links as well but was worried that conceivably an=20 >>> implementation could >>> use link LSAs exclusively for next-hop computation (they are needed=20 >>> for next-hop >>> computation on NBMA links). Are there other opinions on this? >>> >>> Thanks, >>> Acee >>> >>> =20 >>> >>>> Manoj >>>> >>>> -----Original Message----- >>>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of=20 >>>> Paul >>>> Wells >>>> Sent: Wednesday, March 08, 2006 6:01 PM >>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>> Subject: Re: OAPFv3: what is the use of prefixes in Link LSA >>>> >>>> Hi Manoj, >>>> >>>> Goyal, Manoj wrote: >>>> >>>> >>>> =20 >>>> >>>>> HI, >>>>> >>>>> In ospfv3 the intra-area-prefix LSAs have all the prefixes and=20 >>>>> routing >>>>> =20 >>>>> =20 >>>> >>>> >>>> table >>>> >>>> >>>> =20 >>>> >>>>> should be calculated using them. Then what is really the use of=20 >>>>> having >>>>> >>>>> the prefixes of the link in its link-LSA. >>>>> =20 >>>>> =20 >>>> >>>> >>>> For broadcast and nbma links, the prefixes in the link lsas are=20 >>>> used by >>>> =20 >>> >>> >>> >>> =20 >>> >>>> the DR to construct the intra-area prefix lsa associated with the=20 >>>> network lsa. >>>> >>>> >>>> >>>> =20 >>>> >>>>> Is there a case where the router will not include some prefixes in >>>>> intra-area-prefix LSA >>>>> >>>>> but advertise in the link-LSA? I don't see any such case. >>>>> =20 >>>>> =20 >>>> >>>> >>>> Prefixes for broadcast/nbma transit links are advertised by the DR=20 >>>> on behalf of the attached routers, and not by the non-DR routers=20 >>>> themselves. But if you are asking if some of the prefixes won't=20 >>>> appear >>>> =20 >>> >>> >>> >>> =20 >>> >>>> in _any_ intra-area prefix lsa, then no, I don't think so. >>>> >>>> Regards, >>>> Paul >>>> >>>> >>>> >>>> =20 >>>> >>>>> Thanks, >>>>> >>>>> Manoj >>>>> =20 >>>>> =20 >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> The information contained in this message may be privileged >>>> and confidential and protected from disclosure. If the reader >>>> of this message is not the intended recipient, or an employee >>>> or agent responsible for delivering this message to the >>>> intended recipient, you are hereby notified that any reproduction, >>>> dissemination or distribution of this communication is strictly >>>> prohibited. If you have received this communication in error, >>>> please notify us immediately by replying to the message and >>>> deleting it from your computer. Thank you. Tellabs >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> >>>> >>>> =20 >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> The information contained in this message may be privileged >>> and confidential and protected from disclosure. If the reader >>> of this message is not the intended recipient, or an employee >>> or agent responsible for delivering this message to the >>> intended recipient, you are hereby notified that any reproduction, >>> dissemination or distribution of this communication is strictly >>> prohibited. If you have received this communication in error, >>> please notify us immediately by replying to the message and >>> deleting it from your computer. Thank you. Tellabs >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> =20 >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 16 08:27:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsWC-0004PE-QG for ospf-archive@LISTS.IETF.ORG; Thu, 16 Mar 2006 08:27:56 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJsW9-0001Tl-JC for ospf-archive@LISTS.IETF.ORG; Thu, 16 Mar 2006 08:27:56 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0003E8F5@wildebeest.ease.lsoft.com>; Thu, 16 Mar 2006 8:27:52 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-OpenPGP-Fingerprint:X-OpenPGP-KeyID:X-Priority:MIME-Version:Content-Type:X-PCS-MailScanner-Information:X-PCS-MailScanner:X-PCS-MailScanner-SpamCheck:X-PCS-MailScanner-From:Message-ID:Date:Reply-To:Sender:From:Organization:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=ARxJ3nqYHCnwikcvFXInnep5/StIRhpaBJlnumf3I056RC26Ymag9teYz0/Q0VpT+adBajc90h+Xxjptug9K7IXBiK2AnjKai1QNlYfUylS8T3QllUxNLWyqJcAGdBss; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102358533 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 16 Mar 2006 08:27:51 -0500 Received: from 217.25.84.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 16 Mar 2006 08:17:50 -0500 Received: from proxy-ttk.pcs-net.net (meltdown.pcs-net.net [217.25.84.84]) by mail-3.pcs-net.net (Postfix) with ESMTP id 792BE11DC0E; Thu, 16 Mar 2006 16:17:45 +0300 (MSK) X-OpenPGP-Fingerprint: D4D7 F850 DDE5 B418 BF21 4600 9F71 80EA 73FA 758E X-OpenPGP-KeyID: 0x73FA758E X-Priority: High MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PCS-MailScanner-Information: Please contact the ISP for more information. X-PCS-MailScanner: Found to be clean X-PCS-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-PCS-MailScanner-From: v.blazhkun@pcs-net.net Message-ID: Date: Thu, 16 Mar 2006 16:17:45 +0300 Reply-To: Mailing List Sender: Mailing List From: "Vladimir S. Blazhkun" Organization: Personal Communications Systems, LLC Subject: ospfIfRxBadPacket NOTIFICATION-TYPE To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.2 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hello, please help me to understand ospfIfRxBadPacket NOTIFICATION-TYPE correctly. As i red in RFC2328 (section 8.2) and RFC1850, this trap should be sent if router cannot determine which interface it should associate with incoming packet, right? Which real life situations can cause this? -- Vladimir S. Blazhkun, Personal Communications Systems, LLC. Leading IP NCC Specialist, Work phone: +7 495 7847617 ext. 1101. JNCIA-J JNCIA-M #773 JNCIS-M #1100 JNCIP-M #289 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 16 08:46:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsoS-00044k-Kw for ospf-archive@LISTS.IETF.ORG; Thu, 16 Mar 2006 08:46:48 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJsoS-0001zr-FW for ospf-archive@LISTS.IETF.ORG; Thu, 16 Mar 2006 08:46:48 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0003E8FB@wildebeest.ease.lsoft.com>; Thu, 16 Mar 2006 8:46:47 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:X-Mailer:Content-Type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=k3ISj7HvuxraRRgrw9+pJKTOafAgUZToYIo1Y8mLIttrvgMmOe54icNjDnRL31ZGu8bs+ROwI/W6v55sNOZd9HLQm5b1swRJFD6jt0qeSZYiYk9AxU2n1nIB2X4Onlxe; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102359282 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 16 Mar 2006 08:46:48 -0500 Received: from 216.148.248.31 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 16 Mar 2006 08:36:45 -0500 Received: by sysamawil1ce.systems.textron.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Mar 2006 08:36:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Message-ID: Date: Thu, 16 Mar 2006 08:36:39 -0500 Reply-To: Mailing List Sender: Mailing List From: "Doros, Michael" Subject: Re: ospfIfRxBadPacket NOTIFICATION-TYPE To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Vladimir, It is not so much that the router cannot determine where the packet came from, but that the packet came in on a non-virtual link. -Michael -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vladimir S. Blazhkun Sent: Thursday, March 16, 2006 8:18 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: ospfIfRxBadPacket NOTIFICATION-TYPE Hello, please help me to understand ospfIfRxBadPacket NOTIFICATION-TYPE correctly. As i red in RFC2328 (section 8.2) and RFC1850, this trap should be sent if router cannot determine which interface it should associate with incoming packet, right? Which real life situations can cause this? -- Vladimir S. Blazhkun, Personal Communications Systems, LLC. Leading IP NCC Specialist, Work phone: +7 495 7847617 ext. 1101. JNCIA-J JNCIA-M #773 JNCIS-M #1100 JNCIP-M #289 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 16 18:18:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1jT-0001SZ-6r for ospf-archive@LISTS.IETF.ORG; Thu, 16 Mar 2006 18:18:15 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1jS-0006dt-To for ospf-archive@LISTS.IETF.ORG; Thu, 16 Mar 2006 18:18:15 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0003EA56@wildebeest.ease.lsoft.com>; Thu, 16 Mar 2006 18:18:10 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=oje5HsTKlR1ExsccZnEtSZ3JXI9bnBmO352ezY7srsNLn6KYeCALyEOE8Ezr97h2E1B0DdUSjMv06ZL8zn6X9adKiJatyV9lwieKFSXDAUfPIti9sBYj3gdxHZBco1ix; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102405483 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 16 Mar 2006 18:18:10 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 16 Mar 2006 18:18:09 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 16 Mar 2006 15:18:09 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2GNI9Gv004812 for ; Thu, 16 Mar 2006 15:18:09 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 15:18:08 -0800 Received: from [128.107.177.148] ([128.107.177.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 15:18:08 -0800 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 23:18:08.0559 (UTC) FILETIME=[E2F503F0:01C6494F] Message-ID: <4419F232.6020701@cisco.com> Date: Thu, 16 Mar 2006 18:18:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ospfIfRxBadPacket NOTIFICATION-TYPE To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi Vladmir, Vladimir S. Blazhkun wrote: > Hello, please help me to understand ospfIfRxBadPacket NOTIFICATION-TYPE > correctly. > > As i red in RFC2328 (section 8.2) and RFC1850, this trap should be sent > if router cannot determine which interface it should associate with > incoming packet, right? Right. > > Which real life situations can cause this? > The most common example would be a misconfigured address on a router. The router generating the trap would not be able to match the packet source address to its subnet on the receiving interface. Hope this helps, Acee From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Sat Mar 18 23:29:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKpYF-0006ph-5n for ospf-archive@LISTS.IETF.ORG; Sat, 18 Mar 2006 23:29:59 -0500 Received: from lime.ease.lsoft.com ([209.119.0.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKpYB-0004wq-Ul for ospf-archive@LISTS.IETF.ORG; Sat, 18 Mar 2006 23:29:59 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.54) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.000B2622@LIME.ease.lsoft.com>; Sat, 18 Mar 2006 23:28:31 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Antivirus:X-Antivirus-Status:Message-ID:Date:Reply-To:Sender:From:Organization:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=CbeQE0l8Sod+VcKbm0fik4mlP37zPyFJTL/DLq1ijwGA9iVUxtasUFxgEz52O7SETTKJgWMY5lWT51mjUofoZ+99sQyUwp5fzd8ZwJdyTmxFzngkP4e1vfXwXBIYYnvU; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102561115 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 18 Mar 2006 23:29:50 -0500 Received: from 158.202.43.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 18 Mar 2006 23:19:50 -0500 Received: from zMs.furukawa.co.jp (localhost [127.0.0.1]) by zMs.furukawa.co.jp (8.12.11/8.12.11) with ESMTP id k2J4Jlo7010382 for ; Sun, 19 Mar 2006 13:19:47 +0900 (JST) Received: from netgw.inf.furukawa.co.jp (PIXPAT [158.202.43.38]) by zMs.furukawa.co.jp (8.12.11/8.12.11) with ESMTP id k2J4JlbP010377 for ; Sun, 19 Mar 2006 13:19:47 +0900 (JST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by netgw.inf.furukawa.co.jp (8.11.6/3.7W-SYSTEM CENTER MAIL SERVER 1.0) with ESMTP id k2J4JkA01125 for ; Sun, 19 Mar 2006 13:19:46 +0900 (JST) User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0611-2, 2006/03/17), Outbound message X-Antivirus-Status: Clean Message-ID: <441CDBDE.8000503@inf.furukawa.co.jp> Date: Sun, 19 Mar 2006 13:19:42 +0900 Reply-To: Mailing List Sender: Mailing List From: Hideaki HAYASHI Organization: FURUKAWA NETWORK SOLUTION Subject: OSPF VRF MIB To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.4 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi, all I seems that OSPF-MIB and OSPF-TRAP-MIB do not support VRF specific information. For example, as ospfNbrStateChange does not contain VRF infomation, it is difficult to grasp which neighbor state change. We implemented OSPF MIB (OSPF-TRAP-MIB) with VRF information as enterprise MIB. I need standard OSPF MIB (OSPF-TRAP-MIB) with VRF information. Please comment. regards, -- Hideaki From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 20 09:02:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKxY-0000M5-0x for ospf-archive@LISTS.IETF.ORG; Mon, 20 Mar 2006 09:02:12 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLKxX-00030o-Hj for ospf-archive@LISTS.IETF.ORG; Mon, 20 Mar 2006 09:02:11 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0003F0B7@wildebeest.ease.lsoft.com>; Mon, 20 Mar 2006 9:02:10 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=nrl4EsEXtcfR2YPldusCG5Uu5zzV9+YnszKnL0IX2KXzQ9D20sEu2eTUQ0dXjUSRDv49OK/UK2pdcicbVqVkFBujohMoF7yvt2Dt2h9DkA4JzXz8zg7ooO7mGDbP54/a; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102696079 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Mar 2006 09:02:10 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Mar 2006 09:02:10 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Mar 2006 06:02:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208"; a="23987728:sNHT24471600" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2KE29VU021376 for ; Mon, 20 Mar 2006 09:02:09 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 09:02:09 -0500 Received: from [10.82.224.63] ([10.82.224.63]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 09:02:08 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01M01FIR1AIA000TQD@omega7.wr.usgs.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 14:02:09.0022 (UTC) FILETIME=[E0C6A1E0:01C64C26] Message-ID: <441EB5E0.5080104@cisco.com> Date: Mon, 20 Mar 2006 09:02:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01M01FIR1AIA000TQD@omega7.wr.usgs.gov> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi Pat, I don't think we need any changes to the specifications to handle the situation. Possibly, RFC 3101 section 2.3 could have explicitly stated that if an NSSA ASBR must chose a forwarding address it must be one of the NSSAs interface address but this is implied since the normal forwarding address must be part of the NSSA. The router solely attached to two NSSAs should generate two type 7 LSAs. Since it is connected to any regular areas, it will not generate a type 5 and the P bit will be set. The ABRs doing the respective NSSA should originate type 5 LSAs that are not equivalent since the forwarding addresses and possibly metrics will be different. Regarding all the non-standard area filtering techniques, we don't even want to try and consider them in the specifications since one break all sorts of things by using them. Thanks, Acee Pat Murphy - (650)329-4044 wrote: >Regarding the initial question > > > >>Can someone throw some light on why the P bit must be clear in >>the case when an ASBR originates both a type 7 and type 5 LSA >>for the same network? >> >> > >here is a minor thought. When a Type 5 LSA is originated the forwarding address >is set based on the discussion in RFC 2328 Section 12.4.4.1. This need not (and >should not) be an address from a directly attached NSSA and could even be >0.0.0.0. As Acee and others have pointed out, a Type 7 LSA with the P-bit set >must have a non-zero forwarding address from the NSSA. If one attempted to >advertise such beasts simultaneously wouldn't the translation process of RFC 3101 >Section 3.2 Step (2) > > ...then a Type-5 LSA > should be generated if there is currently no Type-5 LSA > originating from this router corresponding to the Type-7 LSA's > network, or there is an existing Type-5 LSA and either it > corresponds to a local OSPF external source whose path type > and metric is less preferred (see Section 2.5 step (6), parts > (b) and (d)), or it doesn't and the Type-5 LSA's path type or > cost(s) have changed (See Section 2.5 step (5)) or the > forwarding address no longer maps to a translatable Type-7 > LSA. > >cause these two originations to thrash? Keep in mind that every NSSA ABR is a >potential translator. With the P-bit always clear, this is not an implementation >issue. > >I would like to see a minor change in Type 5 originations, namely that a >non-zero forwarding address must be computed from the OSPF domain's "transit" >topology. It should never be chosen from a stub area or NSSA. If the true >forwarding address is in a directly attached stub area or NSSA, the Type 5 LSA's >forwarding address is simply set to 0.0.0.0; The only exception to this rule >happens during Type-7 translation. This would eliminate the requirement for the >last line in > > When an NSSA border router originates both a Type-5 LSA and a Type-7 > LSA for the same network, then the P-bit must be clear in the Type-7 > LSA so that it isn't translated into a Type-5 LSA by another NSSA > border router. If the border router only originates a Type-7 LSA, it > may set the P-bit so that the network may be aggregated/propagated > during Type-7 translation. If an NSSA's border router originates a > Type-5 LSA with a forwarding address from the NSSA, it should also > originate a Type-7 LSA into the NSSA. > >If one really wants this behavior they need only set the P-bit and let >translation originate the Type 5 LSA. Type 5 LSAs with a forwarding address from >a directly attached NSSA are never installed (See the last paragraph of RFC 3101 >Section 2.3 Step (3)) on NSSA border routers. Thus they create the potential for >black holes. I think this is a loose point in the base OSPF spec. While the NSSA >spec handles it, given all of the available OSPF implementation knobs for >filtering external advertisements, careful implementation is required. Since it >is not necessary for feature, why have it? > >Pat > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 20 09:24:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLIl-0005Na-UA for ospf-archive@LISTS.IETF.ORG; Mon, 20 Mar 2006 09:24:07 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLIk-0003kF-IJ for ospf-archive@LISTS.IETF.ORG; Mon, 20 Mar 2006 09:24:07 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0003EFE5@wildebeest.ease.lsoft.com>; Mon, 20 Mar 2006 9:24:00 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=b09EgVbyf9nHJE8LnWqeaeJKDVsppcZn7S+tzfo8c//54srssrQQNFU2NycP4aqmhW+5qGCRbyrGZ7aNtKyc7TClgF7BkTyIRcBQWXbOrh52xlSs8GLQ5sqn3kFVDPkj; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102697623 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Mar 2006 09:24:00 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Mar 2006 09:24:00 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Mar 2006 09:23:58 -0500 X-IronPort-AV: i="4.03,111,1141621200"; d="scan'208"; a="84513194:sNHT28592652" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2KEO1VU025948 for ; Mon, 20 Mar 2006 09:24:01 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 09:23:58 -0500 Received: from [10.82.224.63] ([10.82.224.63]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 09:23:58 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <441CDBDE.8000503@inf.furukawa.co.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 14:23:58.0327 (UTC) FILETIME=[ED2EB870:01C64C29] Message-ID: <441EBAFE.1020600@cisco.com> Date: Mon, 20 Mar 2006 09:23:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF VRF MIB To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <441CDBDE.8000503@inf.furukawa.co.jp> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Hideaki, Hideaki HAYASHI wrote: >Hi, all > >I seems that OSPF-MIB and OSPF-TRAP-MIB do not support VRF specific >information. > >For example, as ospfNbrStateChange does not contain VRF infomation, >it is difficult to grasp which neighbor state change. > >We implemented OSPF MIB (OSPF-TRAP-MIB) with VRF information as >enterprise MIB. > > I don't think this was the right thing to do. >I need standard OSPF MIB (OSPF-TRAP-MIB) with VRF information. > >Please comment. > > When you have a separate VRF you have a separate OSPF instance and the whole OSPF MIB needs to be instantiated (as well as other MIBs). Multiple instances can be handled with separate SNMPv3 contexts and we agreed on this direction a couple years back. http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0301&L=OSPF&D=0&I=-3&P=3128 Hope this helps, Acee >regards, > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 20 12:14:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNy7-0005xO-MP for ospf-archive@LISTS.IETF.ORG; Mon, 20 Mar 2006 12:14:59 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNy7-0002JV-Fp for ospf-archive@LISTS.IETF.ORG; Mon, 20 Mar 2006 12:14:59 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.0003F18D@wildebeest.ease.lsoft.com>; Mon, 20 Mar 2006 12:14:58 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-VMS-To:X-VMS-Cc:MIME-version:Content-type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=Jw7bmrlKXqpkQhf15EiMFooek24mR60b8r3BBSzNnDZXTEFL4i8HAw2IXOg8SzGOKadX2w+K+iwJUD/6gvcJydOTTSFZHeheunokTt0zpCrzIr7AGy6Ac1oXXvomAuoB; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102714863 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Mar 2006 12:14:58 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Mar 2006 12:01:09 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01M09T8HAUDS000W4P@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Mar 2006 08:59:07 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: pmurphy MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01M09T8HAVBM000W4P@omega7.wr.usgs.gov> Date: Mon, 20 Mar 2006 08:59:07 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Sorry Acee, >Possibly, RFC 3101 section 2.3 could have explicitly stated >that if an NSSA ASBR must chose a forwarding address it must >be one of the NSSAs interface address but this is implied >since the normal forwarding address must be part of the NSSA. I wasn't suggesting any change to RFC 3101. I thought it already said that in Section 2.3 via the following wording: Normally the next hop address of an installed AS external route learned by an NSSA ASBR from an adjacent AS points at one of the adjacent AS's gateway routers. If this address belongs to a network connected to the NSSA ASBR via one of its NSSAs' active interfaces, then the NSSA ASBR copies this next hop address into the forwarding address field of the route's Type-7 LSA that is originated into this NSSA, as is currently done with Type-5 LSAs. (See [OSPF] Section 12.4.4.1.) For an NSSA with no such network the forwarding address field may only be filled with an address from one of the its active interfaces or 0.0.0.0... The non-zero-forwarding address of any Type 7 LSA originated into a specific NSSA must come from one of that NSSA's active interfaces. Perhaps it could be better worded. But, if you read it carefully ("into this NSSA"), that is what it says. So if a Type-7 LSA is originated for the same prefix into two different directly attached NSSAs with its P-bit set, then these two LSAs MUST have different non-zero forwarding addresses chosen from their respective NSSA's active interfaces. As for my recommendation, it is an old errata that John and I discussed and agreed to years back. I think he had planned to add it to a list of minor errata to RFC 2328. Perhaps that already happen. I added the sentence... ...If an NSSA's border router originates a Type-5 LSA with a forwarding address from the NSSA, it should also originate a Type-7 LSA into the NSSA. to RFC 3101's Section 2.4, Paragraph 2, as an interim measure. Otherwise an NSSA with multiple ABRs can black hole traffic bound for the Type-5 LSA's prefix. I will send the recommendation under a different posting leaving out any reference to RFC 3101. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 20 12:51:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOXn-0003tG-WA for ospf-archive@LISTS.IETF.ORG; Mon, 20 Mar 2006 12:51:52 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLOXm-0003hx-Q7 for ospf-archive@LISTS.IETF.ORG; Mon, 20 Mar 2006 12:51:51 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0003F1A7@wildebeest.ease.lsoft.com>; Mon, 20 Mar 2006 12:51:50 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-VMS-To:X-VMS-Cc:MIME-version:Content-type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=C3xTH02VqGpIXFgp6qer4+JtPOd4uWzzKFqA+7KyHMj1T/nSvp0L2mQNc7fiMrI3dUSdpLWuO5w45sXpODgDBZUTiCr9xkMCSxB2l0FFuqmhRrnsiYshEyHCY8XLWaWa; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102719376 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Mar 2006 12:51:50 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Mar 2006 12:51:50 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01M09V0BRCNC000W4P@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Mar 2006 09:49:49 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01M09V0BRCNE000W4P@omega7.wr.usgs.gov> Date: Mon, 20 Mar 2006 09:49:49 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Originating Type 5 LSAs with non-zero forwarding addresses To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab When originating a Type 5 LSA its forwarding address should never be chosen from a stub or Not-So-Stubby-Area (NSSA), unless it is a translation of a Type 7 LSA. To do so would potentially cause traffic destined toward the Type 5 LSA's prefix to be black holed whenever that stub area or NSSA has multiple ABRs. There are several references in RFC 2328 to the selection of a non-zero forwarding address that read... ...when the forwarding address field is non-zero, it should point to a router belonging to another Autonomous System. I recommend the following minor rewording (errata) ...when the forwarding address field is non-zero, it should point to a router belonging to another Autonomous System and MUST be chosen from an area capable of flooding Type 5 LSAs. If no such address exists the forwarding address should be 0.0.0.0. Two such references can be found in Section 12.4.4.1 and Footnote [24]. I don't think there are any others. It might also be worth adding to Appendix A.4.5. The exception is documented in RFC 3101. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 21 06:52:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLfPQ-0006TD-US for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 06:52:20 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLfPP-00040I-O7 for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 06:52:20 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0003F384@wildebeest.ease.lsoft.com>; Tue, 21 Mar 2006 6:52:19 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-ID:Date:Reply-To:Sender:From:Organization:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=Gc+WBJLHlZhI9aaF6Mf8T0RZxwirTH8MXNtmXzjdnsbGNo9V0CQHqucJDvAsH9GjwFvs2SAHSJGd4kQskXpyVftNN6dyiGiDtqiFeXuXbZCvi+ytp5wZz2AsepaN08L3; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102786330 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Mar 2006 06:52:19 -0500 Received: from 194.126.115.47 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Mar 2006 06:42:18 -0500 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by localhost.localdomain with esmtp (Exim 4.60) (envelope-from ) id 1FLfFf-0005A3-Om for OSPF@peach.ease.lsoft.com; Tue, 21 Mar 2006 13:42:15 +0200 User-Agent: KMail/1.9.1 References: <01M09V0BRCNE000W4P@omega7.wr.usgs.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200603211342.14795.hasso@estpak.ee> Date: Tue, 21 Mar 2006 13:42:14 +0200 Reply-To: Mailing List Sender: Mailing List From: Hasso Tepper Organization: Elion Enterprises Ltd. Subject: Re: Originating Type 5 LSAs with non-zero forwarding addresses To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01M09V0BRCNE000W4P@omega7.wr.usgs.gov> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Pat Murphy - (650)329-4044 wrote: > When originating a Type 5 LSA its forwarding address should never be > chosen from a stub or Not-So-Stubby-Area (NSSA), unless it is a > translation of a Type 7 LSA. To do so would potentially cause traffic > destined toward the Type 5 LSA's prefix to be black holed whenever that > stub area or NSSA has multiple ABRs. There are several references in > RFC 2328 to the selection of a non-zero forwarding address that read... > > ...when the forwarding address field is non-zero, it should point > to a router belonging to another Autonomous System. > > I recommend the following minor rewording (errata) > > ...when the forwarding address field is non-zero, it should point > to a router belonging to another Autonomous System and MUST be chosen > from an area capable of flooding Type 5 LSAs. If no such address > exists the forwarding address should be 0.0.0.0. > > Two such references can be found in Section 12.4.4.1 and Footnote [24]. > I don't think there are any others. It might also be worth adding to > Appendix A.4.5. The exception is documented in RFC 3101. Is anyone working on update to RFC2328? I just had discussion regarding architectural constants in RFC2328 appendix B and how much they are honoured nowadays. I'd really like to see update to avoid such discussions in the future :). regards, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 21 14:37:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLmfj-0005EM-77 for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 14:37:39 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLmfi-0005Mv-UB for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 14:37:39 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.0003F466@wildebeest.ease.lsoft.com>; Tue, 21 Mar 2006 14:37:38 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=QKji8kOqp/Qz9cHb9gRt6amDvdSurwoqcY2lMcKi1sET+NcZHAlMVKCYLh2kW+MndBXPVDZTaK78vVlS4DWE6SUsbHNnlfqC8vRftLmwLnNnrW7bXnW2Nt87QDxtQqZH; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102828062 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Mar 2006 14:37:38 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Mar 2006 14:37:37 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2006 11:37:37 -0800 X-IronPort-AV: i="4.03,115,1141632000"; d="scan'208"; a="1786962582:sNHT35273500" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2LJbaYg002868 for ; Tue, 21 Mar 2006 11:37:36 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 11:37:36 -0800 Received: from [10.89.20.106] ([10.89.20.106]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 11:37:35 -0800 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01M09T8HAVBM000W4P@omega7.wr.usgs.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2006 19:37:35.0881 (UTC) FILETIME=[E7BB5790:01C64D1E] Message-ID: <442055FE.5010306@cisco.com> Date: Tue, 21 Mar 2006 14:37:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01M09T8HAVBM000W4P@omega7.wr.usgs.gov> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi Pat, Pat Murphy - (650)329-4044 wrote: >Sorry Acee, > > > >>Possibly, RFC 3101 section 2.3 could have explicitly stated >>that if an NSSA ASBR must chose a forwarding address it must >>be one of the NSSAs interface address but this is implied >>since the normal forwarding address must be part of the NSSA. >> >> > >I wasn't suggesting any change to RFC 3101. I thought it already said >that in Section 2.3 via the following wording: > > Normally the next hop address of an installed AS external route > learned by an NSSA ASBR from an adjacent AS points at one of the > adjacent AS's gateway routers. If this address belongs to a network > connected to the NSSA ASBR via one of its NSSAs' active interfaces, > then the NSSA ASBR copies this next hop address into the forwarding > address field of the route's Type-7 LSA that is originated into this > NSSA, as is currently done with Type-5 LSAs. (See [OSPF] Section > 12.4.4.1.) For an NSSA with no such network the forwarding address > field may only be filled with an address from one of the its active > interfaces or 0.0.0.0... > > I was referring to the case covered in the next paragraph. If I had my choice today, I'd qualify the text to limit the choice to NSSA addresses. By implied, I meant that it was covered in the paragraph you quote. When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router's internal addresses (provided internal addressing is supported). If internal addresses are not available, preference should be given to the router's active OSPF stub network addresses. These choices avoid the possible extra hop that may happen when a transit network's address is used. When the interface whose IP address is the LSA's forwarding address transitions to a Down state (see [OSPF] Section 9.3), the router must select a new forwarding address for the LSA and then re- originate it. If one is not available the LSA should be flushed. Thanks, Acee >The non-zero-forwarding address of any Type 7 LSA originated into a >specific NSSA must come from one of that NSSA's active interfaces. >Perhaps it could be better worded. But, if you read it carefully ("into >this NSSA"), that is what it says. > >So if a Type-7 LSA is originated for the same prefix into two different >directly attached NSSAs with its P-bit set, then these two LSAs MUST >have different non-zero forwarding addresses chosen from their >respective NSSA's active interfaces. > >As for my recommendation, it is an old errata that John and I discussed >and agreed to years back. I think he had planned to add it to a list of >minor errata to RFC 2328. Perhaps that already happen. I added the >sentence... > > ...If an NSSA's border router originates a > Type-5 LSA with a forwarding address from the NSSA, it should also > originate a Type-7 LSA into the NSSA. > >to RFC 3101's Section 2.4, Paragraph 2, as an interim measure. Otherwise >an NSSA with multiple ABRs can black hole traffic bound for the Type-5 >LSA's prefix. > >I will send the recommendation under a different posting leaving out any >reference to RFC 3101. > >Pat > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 21 14:42:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLmkK-0007z2-FO for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 14:42:24 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLmkK-0005Zd-8D for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 14:42:24 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0003F452@wildebeest.ease.lsoft.com>; Tue, 21 Mar 2006 14:42:24 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=nnPX0yCMeK2U+gG72i2iN5UgmzYxQ9bypENEMU+js56DEVPvNGGVXSaePm9HJilzLIs7y1aF825ZJhb3izi4FhL5SFMsaaTMzBvKlQZJt2ZN4a1AkQVbV2Asa8avUx5f; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102828416 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Mar 2006 14:42:23 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Mar 2006 14:42:23 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2006 11:42:22 -0800 X-IronPort-AV: i="4.03,115,1141632000"; d="scan'208"; a="418948031:sNHT24829200" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2LJgLw5019997 for ; Tue, 21 Mar 2006 11:42:22 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 11:42:21 -0800 Received: from [10.89.20.106] ([10.89.20.106]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 11:42:21 -0800 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01M09V0BRCNE000W4P@omega7.wr.usgs.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2006 19:42:21.0709 (UTC) FILETIME=[92193BD0:01C64D1F] Message-ID: <4420571D.9040608@cisco.com> Date: Tue, 21 Mar 2006 14:42:21 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Originating Type 5 LSAs with non-zero forwarding addresses To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01M09V0BRCNE000W4P@omega7.wr.usgs.gov> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi Pat, Agree with the update. Over the years, I've seen this bug fixed in several implementations. Thanks, Acee Pat Murphy - (650)329-4044 wrote: >When originating a Type 5 LSA its forwarding address should never be >chosen from a stub or Not-So-Stubby-Area (NSSA), unless it is a >translation of a Type 7 LSA. To do so would potentially cause traffic >destined toward the Type 5 LSA's prefix to be black holed whenever that >stub area or NSSA has multiple ABRs. There are several references in RFC >2328 to the selection of a non-zero forwarding address that read... > > ...when the forwarding address field is non-zero, it should point > to a router belonging to another Autonomous System. > >I recommend the following minor rewording (errata) > > ...when the forwarding address field is non-zero, it should point > to a router belonging to another Autonomous System and MUST be chosen > from an area capable of flooding Type 5 LSAs. If no such address > exists the forwarding address should be 0.0.0.0. > >Two such references can be found in Section 12.4.4.1 and Footnote [24]. >I don't think there are any others. It might also be worth adding to >Appendix A.4.5. The exception is documented in RFC 3101. > >Pat > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 21 14:48:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLmqN-0003X9-8l for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 14:48:39 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLmqN-0005rH-1J for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 14:48:39 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.0003F3B2@wildebeest.ease.lsoft.com>; Tue, 21 Mar 2006 14:48:39 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=UQqk4mw20LVMwTb20yBaJuppwjyYsbfJm3Fxyyo6qXv91zsuTDSqETZV+GVvJwa6kA/eHrkhFOToDcl3axdlg6IzkR6Ko1iBwSj7phYiyW7oqNayoCcNbMTX8PAt9tRF; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102828733 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Mar 2006 14:48:38 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Mar 2006 14:48:38 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 21 Mar 2006 11:48:36 -0800 X-IronPort-AV: i="4.03,115,1141632000"; d="scan'208"; a="316762893:sNHT26279128" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2LJma7T004659 for ; Tue, 21 Mar 2006 11:48:36 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 11:48:36 -0800 Received: from [10.89.20.106] ([10.89.20.106]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 11:48:35 -0800 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01M09V0BRCNE000W4P@omega7.wr.usgs.gov> <200603211342.14795.hasso@estpak.ee> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2006 19:48:35.0521 (UTC) FILETIME=[70E86B10:01C64D20] Message-ID: <44205892.2040208@cisco.com> Date: Tue, 21 Mar 2006 14:48:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Originating Type 5 LSAs with non-zero forwarding addresses To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200603211342.14795.hasso@estpak.ee> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hasso Tepper wrote: >Pat Murphy - (650)329-4044 wrote: > > >>When originating a Type 5 LSA its forwarding address should never be >>chosen from a stub or Not-So-Stubby-Area (NSSA), unless it is a >>translation of a Type 7 LSA. To do so would potentially cause traffic >>destined toward the Type 5 LSA's prefix to be black holed whenever that >>stub area or NSSA has multiple ABRs. There are several references in >>RFC 2328 to the selection of a non-zero forwarding address that read... >> >> ...when the forwarding address field is non-zero, it should point >> to a router belonging to another Autonomous System. >> >>I recommend the following minor rewording (errata) >> >> ...when the forwarding address field is non-zero, it should point >> to a router belonging to another Autonomous System and MUST be chosen >> from an area capable of flooding Type 5 LSAs. If no such address >> exists the forwarding address should be 0.0.0.0. >> >>Two such references can be found in Section 12.4.4.1 and Footnote [24]. >>I don't think there are any others. It might also be worth adding to >>Appendix A.4.5. The exception is documented in RFC 3101. >> >> > >Is anyone working on update to RFC2328? I just had discussion regarding >architectural constants in RFC2328 appendix B and how much they are >honoured nowadays. I'd really like to see update to avoid such >discussions in the future :). > > Hi Hasso, RFC 2328 is quite stable. We will incorporate the errata as part of going from DS (Draft Standard) to PS (Proposed Standard). While many implementations have allowed modification of the architectural constants (especially related to flooding), I'm not sure we need to document this since the defaults haven't changed. Thanks, Acee > >regards, > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 21 15:17:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnIZ-00037W-RA for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 15:17:47 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnIZ-00073k-JR for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 15:17:47 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.0003F4B2@wildebeest.ease.lsoft.com>; Tue, 21 Mar 2006 15:17:47 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=nfYejxRzKkPtE70fYbliPkDrdb3YqZZiG+h5kiCwb6xtS+Y1k99zTZ/VjhETh8KwmyI1Ran1a/nzr5xQn0fpatr+Ixt8ZOMnNtnr8chTBDYymtm3Ol5t83fcz708o85w; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102830308 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Mar 2006 15:17:47 -0500 Received: from 171.71.176.117 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Mar 2006 15:17:47 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 21 Mar 2006 12:17:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2LKHjw7011529 for ; Tue, 21 Mar 2006 12:17:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 12:17:45 -0800 Received: from [10.89.20.106] ([10.89.20.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 12:17:45 -0800 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01M09V0BRCNE000W4P@omega7.wr.usgs.gov> <200603211342.14795.hasso@estpak.ee> <44205892.2040208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2006 20:17:45.0655 (UTC) FILETIME=[8411AC70:01C64D24] Message-ID: <44205F68.4040609@cisco.com> Date: Tue, 21 Mar 2006 15:17:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Originating Type 5 LSAs with non-zero forwarding addresses To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <44205892.2040208@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 See one correction below. Acee Lindem wrote: > Hasso Tepper wrote: > >> Pat Murphy - (650)329-4044 wrote: >> >> >>> When originating a Type 5 LSA its forwarding address should never be >>> chosen from a stub or Not-So-Stubby-Area (NSSA), unless it is a >>> translation of a Type 7 LSA. To do so would potentially cause traffic >>> destined toward the Type 5 LSA's prefix to be black holed whenever that >>> stub area or NSSA has multiple ABRs. There are several references in >>> RFC 2328 to the selection of a non-zero forwarding address that read... >>> >>> ...when the forwarding address field is non-zero, it should point >>> to a router belonging to another Autonomous System. >>> >>> I recommend the following minor rewording (errata) >>> >>> ...when the forwarding address field is non-zero, it should point >>> to a router belonging to another Autonomous System and MUST be chosen >>> from an area capable of flooding Type 5 LSAs. If no such address >>> exists the forwarding address should be 0.0.0.0. >>> >>> Two such references can be found in Section 12.4.4.1 and Footnote [24]. >>> I don't think there are any others. It might also be worth adding to >>> Appendix A.4.5. The exception is documented in RFC 3101. >>> >> >> >> Is anyone working on update to RFC2328? I just had discussion >> regarding architectural constants in RFC2328 appendix B and how much >> they are honoured nowadays. I'd really like to see update to avoid >> such discussions in the future :). >> >> > Hi Hasso, > > RFC 2328 is quite stable. We will incorporate the errata as part of > going from DS (Draft Standard) > to PS (Proposed Standard). Meant PS (Proposed Standard) to DS (Draft Standard). > While many implementations have allowed modification of the > architectural constants (especially related to flooding), I'm not sure > we need to document this since > the defaults haven't changed. > > Thanks, > Acee > >> >> regards, >> >> >> > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 21 15:41:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnf2-0000kt-Rk for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 15:41:01 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnf1-0007we-M3 for ospf-archive@LISTS.IETF.ORG; Tue, 21 Mar 2006 15:41:00 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0003F381@wildebeest.ease.lsoft.com>; Tue, 21 Mar 2006 15:40:59 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-VMS-To:X-VMS-Cc:MIME-version:Content-type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=mV6AXuS/D2ynV8TXCt3eFpXyVQ7Z3ZBoFe6PqaEv94usfrO8OmohIYJTESUdNt736G5Yf/elvAFkV0aCc2c/uaM/3IEVg9wB742z3gyjfMGRwpT98hjfesYAjoX4v62/; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 102831556 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Mar 2006 15:40:59 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Mar 2006 15:40:59 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01M0BF7C31E0000XGQ@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Mar 2006 12:38:55 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01M0BF7C31E2000XGQ@omega7.wr.usgs.gov> Date: Tue, 21 Mar 2006 12:38:55 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 >I was referring to the case covered in the next paragraph. If I had my >choice today, I'd qualify the text to limit the choice to NSSA >addresses. By implied, I meant that it was covered in the paragraph >you quote. I have one small 2 line errata to submit based on someone's earlier posting sometime back about a minor anomaly in 2.5 Step (3). If you like this can be done at the same time. Otherwise RFC 3101 seems to have stood up just fine. I guess its time to take care of this. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 23 17:53:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYgk-0007lZ-4n for ospf-archive@LISTS.IETF.ORG; Thu, 23 Mar 2006 17:53:54 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYgi-0002mI-VN for ospf-archive@LISTS.IETF.ORG; Thu, 23 Mar 2006 17:53:54 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0003F9E0@wildebeest.ease.lsoft.com>; Thu, 23 Mar 2006 17:53:52 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:Content-Type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner; b=TiRhvT6IVojeMJ+3Bm2idL+knLqnJZVLcGJXHnStBH3Loz9rLVIydUrIbb+tPn1ywZl0NYWbQ4w5cqUsY8+hX5oFVSJeNDUTRdM9DUEGt70Rxwp7zJjJOW0T+ZzkzU2c; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 103037508 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 23 Mar 2006 17:53:52 -0500 Received: from 64.233.162.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 23 Mar 2006 17:53:52 -0500 Received: by zproxy.gmail.com with SMTP id 12so624404nzp for ; Thu, 23 Mar 2006 14:53:51 -0800 (PST) Received: by 10.37.12.18 with SMTP id p18mr274353nzi; Thu, 23 Mar 2006 14:53:51 -0800 (PST) Received: by 10.36.147.10 with HTTP; Thu, 23 Mar 2006 14:53:50 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8000_5284034.1143154431134" Message-ID: <45f8514d0603231453j6206bcd8lc31a4b759943a518@mail.gmail.com> Date: Thu, 23 Mar 2006 14:53:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Testing OSPF list To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: List-Unsubscribe: List-Subscribe: List-Owner: X-Spam-Score: 1.0 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ------=_Part_8000_5284034.1143154431134 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, There was a hiccup with the ospf mailing list. It should be back up now and this should serve as a test. Best, --rohit. ------=_Part_8000_5284034.1143154431134 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello,

There was a hiccup with the ospf mailing list. It should be b= ack up now and this should serve as a test.

Best,
--rohit.
------=_Part_8000_5284034.1143154431134-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 23 20:07:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMam1-0004xR-1N for ospf-archive@LISTS.IETF.ORG; Thu, 23 Mar 2006 20:07:29 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMalz-0003mX-RT for ospf-archive@LISTS.IETF.ORG; Thu, 23 Mar 2006 20:07:29 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0003F9B4@wildebeest.ease.lsoft.com>; Thu, 23 Mar 2006 20:07:27 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:Content-Type:References:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner; b=jMbLlqTC1GG7gsRGfRnquLSVvIsN1bS3NnRmGVzWqGzlIE5PxDfQekg2G5QS7d0F4X0gMkasEG7XDLjwjCq6FjaW187AfcTqXSZMcXnnxhpheI7mpFE0Mrat1Q2RHO8d; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 103043058 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 23 Mar 2006 20:07:27 -0500 Received: from 64.233.162.199 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 23 Mar 2006 20:07:27 -0500 Received: by zproxy.gmail.com with SMTP id z3so636803nzf for ; Thu, 23 Mar 2006 17:07:26 -0800 (PST) Received: by 10.36.68.5 with SMTP id q5mr349796nza; Thu, 23 Mar 2006 17:07:26 -0800 (PST) Received: by 10.36.147.10 with HTTP; Thu, 23 Mar 2006 17:07:26 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8552_7493783.1143162446349" References: <45f8514d0603231453j6206bcd8lc31a4b759943a518@mail.gmail.com> Message-ID: <45f8514d0603231707j317f3b65pc0bcddfcbfe1301b@mail.gmail.com> Date: Thu, 23 Mar 2006 17:07:26 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Testing OSPF list To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <45f8514d0603231453j6206bcd8lc31a4b759943a518@mail.gmail.com> Precedence: list List-Help: List-Unsubscribe: List-Subscribe: List-Owner: X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_Part_8552_7493783.1143162446349 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Again. The previous message didn't seem to loop around although I did get one "out-of-office" notice. Sigh. --rohit. On 3/23/06, Rohit Dube wrote: > > Hello, > > There was a hiccup with the ospf mailing list. It should be back up now > and this should serve as a test. > > Best, > --rohit. > ------=_Part_8552_7493783.1143162446349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Again. The previous message didn't seem to loop around although I did get o= ne "out-of-office" notice.

Sigh.
--rohit.

<= span class=3D"gmail_quote">On 3/23/06, Rohit = Dube <dube.rohit@gmail.com&g= t; wrote:
<= div style=3D"direction: ltr;"> Hello,

There was a hiccup with the ospf mailing list. It should be b= ack up now and this should serve as a test.

Best,
--rohit.

------=_Part_8552_7493783.1143162446349-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 23 22:54:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMdO0-0000th-Bw for ospf-archive@LISTS.IETF.ORG; Thu, 23 Mar 2006 22:54:52 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMdNy-0001o1-V3 for ospf-archive@LISTS.IETF.ORG; Thu, 23 Mar 2006 22:54:52 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0003F942@wildebeest.ease.lsoft.com>; Thu, 23 Mar 2006 22:54:50 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:Content-type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner; b=e9mHxhNnE9SkQreHiguTwI711VbR4h4hOiGJpP74cNFOl9qrqsbil8Y+jL8JxouTddRKIOgWWUnB+/QEFpLQk8cGnrhbhgW41Gh4tmyfsnFyNYPVlniNXeqmwQTbwE/Q; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 103049017 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 23 Mar 2006 22:54:47 -0500 Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 23 Mar 2006 22:54:46 -0500 Received: (qmail 6496 invoked by uid 510); 24 Mar 2006 03:54:03 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 24 mar 2006 03:54:03 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1143172443---0-203.199.83.246-6490" Message-ID: <20060324035403.6495.qmail@webmail35.rediffmail.com> Date: Fri, 24 Mar 2006 03:54:03 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: OSPFv2 - Multiple Interfaces Same Subnet To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: List-Unsubscribe: List-Subscribe: List-Owner: X-Spam-Score: 1.6 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multipart mime message --Next_1143172443---0-203.199.83.246-6490 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Broadcast Interfaces (Multiple interfaces in the same subnet):=0ARouter R1:= =0A----------=0AInterfaces: I11(198.10.10.1/24) and I12(198.10.10.2/24)=0A= =0ARouter R2: =0A----------=0AInterface I21(198.10.10.3/24) =0A=0AAt R1 tw= o NBR FSM's can be run for NBR IP:198.10.10.3 (i.e R2) as per=0ARFC 2328 Ap= pendix F(one possible solution).=0A=0AWondering which of the two NBR FSM(s)= would be used to represent "OSPF Neighbor Table" of the standard OSPFv2 MI= B.=0A=0ALooks like "ospfNbrAddressLessIndex" defined in MIB would be of hel= p=0Abut its definition as of now dont allow its usage.=0A=0AAny thoughts?= =0A=0A-Vivek=0A=0A=0A=0A --Next_1143172443---0-203.199.83.246-6490 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0ABroadcast Interfaces (Multiple interfaces in the same subnet):
=0A= Router R1:
=0A----------
=0AInterfaces: I11(198.10.10.1/24) and I12(= 198.10.10.2/24)
=0A
=0ARouter R2:
=0A----------
=0AInterface I= 21(198.10.10.3/24) 
=0A
=0AAt R1 two NBR FSM's can be run for N= BR IP:198.10.10.3 (i.e R2) as per
=0ARFC 2328 Appendix F(one possible so= lution).
=0A
=0AWondering which of the two NBR FSM(s) would be used t= o represent "OSPF Neighbor Table" of the standard OSPFv2 MIB.
= =0A
=0ALooks like "ospfNbrAddressLessIndex" defined in MIB wou= ld be of help
=0Abut its definition as of now dont allow its usage.
= =0A
=0AAny thoughts?
=0A
=0A-Vivek
=0A
=0A
=0A
=0A=0A<= /P>=0A

=0A<= IMG SRC=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigimpress.cgi/www.red= iff.com/signature-home.htm/1963059423@Middle5?OAS_query=3Dnull&PARTNER=3D3"= BORDER=3D0 VSPACE=3D0 HSPACE=3D0>=0A --Next_1143172443---0-203.199.83.246-6490-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 24 00:35:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMewy-0003W8-GH for ospf-archive@LISTS.IETF.ORG; Fri, 24 Mar 2006 00:35:04 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMewx-0005iW-9A for ospf-archive@LISTS.IETF.ORG; Fri, 24 Mar 2006 00:35:04 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.0003FA9E@wildebeest.ease.lsoft.com>; Fri, 24 Mar 2006 0:35:02 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:X-BrightmailFiltered:X-Brightmail-Tracker:X-IronPort-AV:User-Agent:X-Accept-Language:MIME-Version:References:Content-Type:Content-Transfer-Encoding:X-OriginalArrivalTime:Message-ID:Date:Reply-To:Sender:From:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner; b=rfVwYIICY0L44iqm3VB+0qqGWo8GqJhQZj5H0qcJtNS16hNvllCdt+TswWdYqGWhlikXK3atOZ0BLnfZjdOrYJGYbK0IxUUCCFL37ycV+nmME9TUH59xyjYZ+srChUgK; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 103056914 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Mar 2006 00:35:02 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Mar 2006 00:35:00 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Mar 2006 21:35:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,124,1141632000"; d="scan'208"; a="24344071:sNHT26627900" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2O5Z0VU011685 for ; Fri, 24 Mar 2006 00:35:00 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 00:35:00 -0500 Received: from [10.82.209.97] ([10.82.209.97]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 00:35:00 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01M0BF7C31E2000XGQ@omega7.wr.usgs.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2006 05:35:00.0182 (UTC) FILETIME=[B16D1F60:01C64F04] Message-ID: <44238503.1020402@cisco.com> Date: Fri, 24 Mar 2006 00:34:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question regarding the P bit in type-7 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01M0BF7C31E2000XGQ@omega7.wr.usgs.gov> Precedence: list List-Help: List-Unsubscribe: List-Subscribe: List-Owner: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi Pat, Pat Murphy - (650)329-4044 wrote: >>I was referring to the case covered in the next paragraph. If I had my >>choice today, I'd qualify the text to limit the choice to NSSA >>addresses. By implied, I meant that it was covered in the paragraph >>you quote. >> >> > >I have one small 2 line errata to submit based on someone's earlier >posting sometime back about a minor anomaly in 2.5 Step (3). If you like >this can be done at the same time. Otherwise RFC 3101 seems to have >stood up just fine. I guess its time to take care of this. > > I think it's clear in the context of the section. On the other hand, in respinning RFC 2740, I received a number of comments where a sentense or paragraph is taken out of context. I don't think the current document is wrong so errata isn't mandatory. Thanks, Acee >Pat > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 24 16:23:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtkn-0003Ln-IA for ospf-archive@LISTS.IETF.ORG; Fri, 24 Mar 2006 16:23:29 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMtkm-0003hh-BH for ospf-archive@LISTS.IETF.ORG; Fri, 24 Mar 2006 16:23:29 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0003FD3A@wildebeest.ease.lsoft.com>; Fri, 24 Mar 2006 16:23:27 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-ID:Date:Reply-To:Sender:From:Subject:Comments:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=fbSsWv4BX84qan/zzQi3lQYxn9efk7fxsoJTThd3G6iYT/YZ3vAwU5FtxwFM2E4NTVVOpDnoVIYxUa23JTJ0rdEElmDlpe8PHPn8CXMeKJrINxCrCNStlBcH2ueaSqew; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 103125466 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Mar 2006 16:23:27 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Mar 2006 16:23:27 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.54) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.000BCC99@LIME.ease.lsoft.com>; Fri, 24 Mar 2006 16:21:59 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Shift_JIS" Message-ID: Date: Fri, 24 Mar 2006 16:23:22 -0500 Reply-To: Mailing List Sender: Mailing List From: =?Shift_JIS?Q?Hideaki_HAYASHI?= Subject: Re: OSPF VRF MIB Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hi Acee, Thank you for your comment. I read these discussion you pointed. I think that it was best way to rela= te SNMPv3 context to VRF information. regards, --=20 hideaki On Mon, 20 Mar 2006 09:23:58 -0500, Acee Lindem wrote: >Hi Hideaki, > >Hideaki HAYASHI wrote: > >>Hi, all >> >>I seems that OSPF-MIB and OSPF-TRAP-MIB do not support VRF specific >>information. >> >>For example, as ospfNbrStateChange does not contain VRF infomation, >>it is difficult to grasp which neighbor state change. >> >>We implemented OSPF MIB (OSPF-TRAP-MIB) with VRF information as >>enterprise MIB. >> >> >I don't think this was the right thing to do. > >>I need standard OSPF MIB (OSPF-TRAP-MIB) with VRF information. >> >>Please comment. >> >> >When you have a separate VRF you have a separate OSPF instance and the >whole OSPF MIB >needs to be instantiated (as well as other MIBs). Multiple instances can= >be handled with separate >SNMPv3 contexts and we agreed on this direction a couple years back. > >http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0301&L=3DOSPF&= ;D=3D0&I=3D-3&P=3D3128 > >Hope this helps, >Acee > >>regards, >> >> >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 28 05:00:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAzt-0000Mw-Vi for ospf-archive@LISTS.IETF.ORG; Tue, 28 Mar 2006 05:00:21 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOAzt-00029l-O9 for ospf-archive@LISTS.IETF.ORG; Tue, 28 Mar 2006 05:00:21 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00040365@wildebeest.ease.lsoft.com>; Tue, 28 Mar 2006 5:00:20 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-version:X-MIMEOLE:X-Mailer:Content-type:X-Priority:X-MSMail-priority:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=DHZBZpQ3ztXp6x8FyWcl9plXin1icQmUZO83g37WB/DFKxNpv7f4IehfRtFqaC2YzeGOWb1Wv9j3KUxWuScJ2jr6gaArtbsDrInj+hxRqtH+O9V4Nbt/5BV5Q8S1IiRM; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 103452031 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Mar 2006 05:00:20 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 28 Mar 2006 05:00:19 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWU00GEL1Q7FY@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Mar 2006 18:13:19 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWU005MS1Q64J@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Mar 2006 18:13:19 +0800 (CST) Received: from k49110 ([10.110.114.183]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWU0031D1PWW3@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Mar 2006 18:13:09 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_jyaNG+e3oXLHbK/B8eZFkg)" X-Priority: 3 X-MSMail-priority: Normal Message-ID: <001701c6524e$57f3a5b0$b7726e0a@china.huawei.com> Date: Tue, 28 Mar 2006 17:59:45 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: About immediate hello-draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 This is a multi-part message in MIME format. --Boundary_(ID_jyaNG+e3oXLHbK/B8eZFkg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi,all On the IETF 65th meeting, I made a presentation about http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt. we can make a conclusion that immediate hello is very useful.There is a question about immediate hello interoperability. I answer it as following. Only all OSPF routers(include various vendors) support immediate hello, the benefits of immediate hello can be exhibited. If certain router does not support immediate hello in an ospf domain, the convergence time(on p2p networks) or recovery time(on boardcast or NBMA networks) will be same to the level with normal hello and additional hello packets will be increased. Therefore, it is necessary that immediate hello interoperability. In present, many implementations is part of immediate hello. If these implementations all follow immediate hello, the effect is more obvious. Thanks Zengjie --Boundary_(ID_jyaNG+e3oXLHbK/B8eZFkg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT

Hi,all
 On the IETF 65th meeting, I made a presentation about http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt. we can make a conclusion that immediate hello is very useful.There is a question about immediate hello interoperability. I answer it as following.
 
 Only all OSPF routers(include various vendors) support immediate hello, the benefits of immediate hello can be exhibited. If certain router does not support immediate hello in an ospf domain, the convergence time(on p2p networks) or recovery time(on boardcast or NBMA networks) will be same to the level with normal hello and additional hello packets will be increased. Therefore, it is necessary that immediate hello interoperability.
 In present, many implementations is part of immediate hello. If these implementations all follow immediate hello, the effect is more obvious.
 
Thanks
Zengjie
--Boundary_(ID_jyaNG+e3oXLHbK/B8eZFkg)-- From ospf-bounces@ietf.org Tue Mar 28 16:37:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLsS-00053g-4D; Tue, 28 Mar 2006 16:37:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLsR-00053b-A7 for ospf@ietf.org; Tue, 28 Mar 2006 16:37:23 -0500 Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOLsQ-0000BP-4a for ospf@ietf.org; Tue, 28 Mar 2006 16:37:23 -0500 Received: by zproxy.gmail.com with SMTP id f1so31932nzc for ; Tue, 28 Mar 2006 13:37:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=mqu6V+Lp4I9prelmw1OUQnuJrVhkNQipmbmsLBP475i2P82Lv6n1TSEaKE1jWT5cHnOqOkEMJXiWqtR88+eZP7FVsGyRfd0ivR3O2pgva8NbOL2BPM7D0GokLZV9pQLWQY6YRaNFnvBPxFp4c2vYP33BoiDIxH2EH8B5SwH5Az0= Received: by 10.36.74.8 with SMTP id w8mr8167nza; Tue, 28 Mar 2006 13:37:21 -0800 (PST) Received: by 10.36.146.11 with HTTP; Tue, 28 Mar 2006 13:37:21 -0800 (PST) Message-ID: <45f8514d0603281337k79a0f197uc627c65301e754b8@mail.gmail.com> Date: Tue, 28 Mar 2006 13:37:21 -0800 From: "Rohit Dube" To: ospf@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [OSPF] Test message for new ospf list hosted at ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0722048330==" Errors-To: ospf-bounces@ietf.org --===============0722048330== Content-Type: multipart/alternative; boundary="----=_Part_1237_12627172.1143581841800" ------=_Part_1237_12627172.1143581841800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Test .... --rohit. ------=_Part_1237_12627172.1143581841800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Test ....
--rohit.
------=_Part_1237_12627172.1143581841800-- --===============0722048330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0722048330==-- From ospf-bounces@ietf.org Tue Mar 28 16:58:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOMDH-0000gN-7S; Tue, 28 Mar 2006 16:58:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOMDG-0000gI-W6 for ospf@ietf.org; Tue, 28 Mar 2006 16:58:54 -0500 Received: from zproxy.gmail.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOMDF-0000Zw-Q7 for ospf@ietf.org; Tue, 28 Mar 2006 16:58:54 -0500 Received: by zproxy.gmail.com with SMTP id l1so33268nzf for ; Tue, 28 Mar 2006 13:58:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aRDxOmDFcm6Lfenr2Oq3iZgfMeEQ/34AJWGGswtbwqdDYKoZ8idEjmIGf+91umlAR4XaM1kO5eqL/SUcYbN2XG4i5Oxeo7gUKib9aBgpC6UVwUlkLmHGTZzs+lawa1ueSsQk4eX9OpyeiWZDBJ/09D3LhUks0kjnKV3g+LjCTBA= Received: by 10.36.220.20 with SMTP id s20mr5016nzg; Tue, 28 Mar 2006 13:58:53 -0800 (PST) Received: by 10.36.146.11 with HTTP; Tue, 28 Mar 2006 13:58:53 -0800 (PST) Message-ID: <45f8514d0603281358o7971b8dcnebb79f55c04f7fb9@mail.gmail.com> Date: Tue, 28 Mar 2006 13:58:53 -0800 From: "Rohit Dube" To: ospf@ietf.org In-Reply-To: <45f8514d0603281337k79a0f197uc627c65301e754b8@mail.gmail.com> MIME-Version: 1.0 References: <45f8514d0603281337k79a0f197uc627c65301e754b8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [OSPF] Re: Test message for new ospf list hosted at ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1338718242==" Errors-To: ospf-bounces@ietf.org --===============1338718242== Content-Type: multipart/alternative; boundary="----=_Part_1465_33223610.1143583133502" ------=_Part_1465_33223610.1143583133502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline testing again. On 3/28/06, Rohit Dube wrote: > > Test .... > --rohit. > ------=_Part_1465_33223610.1143583133502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline testing again.

On 3/28/06, Rohit Dube <dube.rohit@gmail.com> wrote:
Test ....
--rohit.

------=_Part_1465_33223610.1143583133502-- --===============1338718242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1338718242==-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 29 17:20:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOj1W-0004qO-2E for ospf-archive@LISTS.IETF.ORG; Wed, 29 Mar 2006 17:20:18 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOj1U-0003UV-Rs for ospf-archive@LISTS.IETF.ORG; Wed, 29 Mar 2006 17:20:18 -0500 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.000408C3@wildebeest.ease.lsoft.com>; Wed, 29 Mar 2006 17:20:15 -0500 DomainKey-Signature: q=dns; d=EASE.LSOFT.COM; s=BETA1; c=nofws; h=Received:MIME-Version:Content-Type:Message-ID:Date:Reply-To:Sender:From:Subject:To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive; b=oHYFh6ptiDN4X59AqcX8gOS3xnDjZYTW4GlZ+b4syn0EOzY6gyFG0qSoKbXV5HBnSJK1Vazr11Usg/m2qZwqKYM7fjCaSRTSZU/YObTPc4DlkAthnQhNGsOSvU199lxC; Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.5) with spool id 103674086 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 29 Mar 2006 17:20:14 -0500 Received: from 64.233.162.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 29 Mar 2006 17:20:14 -0500 Received: by zproxy.gmail.com with SMTP id i11so286288nzh for ; Wed, 29 Mar 2006 14:20:14 -0800 (PST) Received: by 10.37.2.1 with SMTP id e1mr118197nzi; Wed, 29 Mar 2006 14:20:14 -0800 (PST) Received: by 10.36.146.6 with HTTP; Wed, 29 Mar 2006 14:20:14 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_797_29735489.1143670814630" Message-ID: <45f8514d0603291420s5ad88e4qea33eae67ceebd5@mail.gmail.com> Date: Wed, 29 Mar 2006 14:20:14 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Mailing list move To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb ------=_Part_797_29735489.1143670814630 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Folks, Later today I will be moving the ospf mailing list to a new (and permanent) address. All those who are subscribed to the list at 3PM (US pacific time) will be autosubscribed to the new list and unsubscribed from the old list. I would therefore recommend (a) refraining from sending technical emails to the list till you see a followup "all clear" message from me (b) sending me private email at dube.rohit@gmail.com if see any problems with the mailing list migration. Thank you, --rohit. PS: When I subscribe you to the new list, the mailing list software will send you a password for the new list along with a welcome message. Please store that message in a safe folder for future reference. ------=_Part_797_29735489.1143670814630 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Folks,

Later today I will be moving the ospf mailing list to a new (= and permanent) address. All those who are subscribed to the list at 3PM (US= pacific time) will be autosubscribed to the new list and unsubscribed from= the old list.  I would therefore recommend (a) refraining from sendin= g technical emails to the list till you see a followup "all clear"= ; message from me (b) sending me private email at=20 dube.rohit@gmail.com if see any= problems with the mailing list migration.

Thank you,
--rohit.
PS: When I subscribe you to the new list, the mailing list software wi= ll send you a password for the new list along with a welcome message. Pleas= e store that message in a safe folder for future reference.
------=_Part_797_29735489.1143670814630-- From ospf-bounces@ietf.org Wed Mar 29 17:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjNm-0007Xw-3G; Wed, 29 Mar 2006 17:43:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjNl-0007Xm-4q for ospf@ietf.org; Wed, 29 Mar 2006 17:43:17 -0500 Received: from nproxy.gmail.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOjNj-00045k-Sv for ospf@ietf.org; Wed, 29 Mar 2006 17:43:17 -0500 Received: by nproxy.gmail.com with SMTP id y38so221756nfb for ; Wed, 29 Mar 2006 14:43:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=utREfc48CSpV3XVZrz4hobsnk+SZG52hJk5cTFLXw5KYIeGhA+1H15aSBRGD3iIG2AhUDpBqzRPxMNx0QxVcbxsjLZeKiWR2+QkCJI0Kwprdnh5l45/Z8a4MPBYgNQgwMEizqQPkPRm+N0kpTq4wihn/nSA00UFDrOIGudS9pe8= Received: by 10.48.212.5 with SMTP id k5mr633688nfg; Wed, 29 Mar 2006 14:43:15 -0800 (PST) Received: by 10.48.209.10 with HTTP; Wed, 29 Mar 2006 14:43:15 -0800 (PST) Message-ID: <455ea23d0603291443o42676338ia5f47844a33547c7@mail.gmail.com> Date: Wed, 29 Mar 2006 14:43:15 -0800 From: "Rohit Dube" To: ospf@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.9 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [OSPF] Test message for new ospf list hosted at ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1176965967==" Errors-To: ospf-bounces@ietf.org --===============1176965967== Content-Type: multipart/alternative; boundary="----=_Part_11052_11637701.1143672195301" ------=_Part_11052_11637701.1143672195301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline new subscriber test. --rohit. ------=_Part_11052_11637701.1143672195301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline new subscriber test.
--rohit.
------=_Part_11052_11637701.1143672195301-- --===============1176965967== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1176965967==-- From ospf-bounces@ietf.org Wed Mar 29 18:17:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjv2-0005lF-Cv; Wed, 29 Mar 2006 18:17:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjv1-0005j0-N9 for ospf@ietf.org; Wed, 29 Mar 2006 18:17:39 -0500 Received: from zproxy.gmail.com ([64.233.162.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOjuy-0005qP-GU for ospf@ietf.org; Wed, 29 Mar 2006 18:17:39 -0500 Received: by zproxy.gmail.com with SMTP id o37so314761nzf for ; Wed, 29 Mar 2006 15:17:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=NpxJVG32BfNvKB2IniNWR2kvx+D/9Q9DEKGP/CYVHSdDwnQGuE6gOwWw03NReryh1Y5ho7Jj5ecZJF3z1I5hNtSVky860UKfj7DwuyqG/xj3L4y9VGejGGYA/V47LtWusUARw20cwjLW8qhB7M5pipND2ojVa8tvMlS2XU3YgME= Received: by 10.36.250.32 with SMTP id x32mr1680840nzh; Wed, 29 Mar 2006 15:17:36 -0800 (PST) Received: by 10.36.146.6 with HTTP; Wed, 29 Mar 2006 15:17:36 -0800 (PST) Message-ID: <45f8514d0603291517p681c5aaeie6f1250818f7dd10@mail.gmail.com> Date: Wed, 29 Mar 2006 15:17:36 -0800 From: "Rohit Dube" To: ospf@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [OSPF] New mailing list X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0066242713==" Errors-To: ospf-bounces@ietf.org --===============0066242713== Content-Type: multipart/alternative; boundary="----=_Part_1241_3080122.1143674256163" ------=_Part_1241_3080122.1143674256163 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Folks, If you are receiving this message, you are on the new OSPF WG mailing list = ( ospf@ietf.org). The old mailing list will be discontinued shortly. Regards, --rohit. ------=_Part_1241_3080122.1143674256163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Folks,

If you are receiving this message, you are on the new OSPF WG= mailing list (ospf@ietf.org). The old= mailing list will be discontinued shortly.

Regards,
--rohit. ------=_Part_1241_3080122.1143674256163-- --===============0066242713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0066242713==-- From ospf-bounces@ietf.org Wed Mar 29 18:32:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOk9U-0002gb-Q9; Wed, 29 Mar 2006 18:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOk9T-0002gW-JV for ospf@ietf.org; Wed, 29 Mar 2006 18:32:35 -0500 Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOk9S-00079x-Cc for ospf@ietf.org; Wed, 29 Mar 2006 18:32:35 -0500 Received: by zproxy.gmail.com with SMTP id i28so291147nzi for ; Wed, 29 Mar 2006 15:32:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=EyIla5oxIGwkfIBD0StPKRZEuNVaTJPlRHuDzzspQhh6FIqutoph7AlQCK9waJwYnjrwhUmRwK8U/D0f80x5ozDPXxzDNtx/G2bgOQl7KJxI2e5uTSjiKUrrd8uhhp3N6uvxh0UKOZ6D8KEXF7kTlNn2PSKWeqQN8f8RhHxZJFA= Received: by 10.36.60.12 with SMTP id i12mr339116nza; Wed, 29 Mar 2006 15:32:34 -0800 (PST) Received: by 10.36.146.6 with HTTP; Wed, 29 Mar 2006 15:32:33 -0800 (PST) Message-ID: <45f8514d0603291532g21f99fd9m61c8f96c1b7d041@mail.gmail.com> Date: Wed, 29 Mar 2006 15:32:33 -0800 From: "Rohit Dube" To: ospf@ietf.org In-Reply-To: <45f8514d0603291517p681c5aaeie6f1250818f7dd10@mail.gmail.com> MIME-Version: 1.0 References: <45f8514d0603291517p681c5aaeie6f1250818f7dd10@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [OSPF] Re: New mailing list X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1586212786==" Errors-To: ospf-bounces@ietf.org --===============1586212786== Content-Type: multipart/alternative; boundary="----=_Part_1377_14664303.1143675153980" ------=_Part_1377_14664303.1143675153980 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello again, The old mailing list has been discontinued. Going forward please use the ospf@ietf.org list for all OSPF WG discussions. best, --rohit. On 3/29/06, Rohit Dube wrote: > > Folks, > > If you are receiving this message, you are on the new OSPF WG mailing lis= t > (ospf@ietf.org). The old mailing list will be discontinued shortly. > > Regards, > --rohit. > ------=_Part_1377_14664303.1143675153980 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello again,

The old mailing list has been discontinued. Going forwa= rd please use the ospf@ietf.org list f= or all OSPF WG discussions.

best,
--rohit.

On 3/29/06, Rohit Dube <dube.rohit@gmail.com> wrote:
Folks,

If you are receiving this mess= age, you are on the new OSPF WG mailing list ( ospf@ietf.org). The old mailing list will be discontinued shortly.
=
Regards,
--r= ohit.

------=_Part_1377_14664303.1143675153980-- --===============1586212786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1586212786==--