From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 01 10:20:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoMO1-0006rk-8E for ospf-archive@megatron.ietf.org; Fri, 01 Jul 2005 10:20:57 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29431 for ; Fri, 1 Jul 2005 10:20:54 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0109567B@cherry.ease.lsoft.com>; Fri, 1 Jul 2005 10:20:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77587217 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 1 Jul 2005 10:20:47 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 1 Jul 2005 10:20:47 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2005 10:20:49 -0400 X-IronPort-AV: i="3.93,250,1115006400"; d="scan'208"; a="60691717:sNHT29982124" 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 j61EKmZs003643; Fri, 1 Jul 2005 10:20:48 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 10:20:09 -0400 Received: from [10.82.217.175] ([10.82.217.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 10:20:11 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200505231945.PAA03257@ietf.org> <42A9E0F9.1020902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2005 14:20:11.0497 (UTC) FILETIME=[FDC0B590:01C57E47] Message-ID: <42C5511C.4020407@cisco.com> Date: Fri, 1 Jul 2005 10:20:12 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-cap-07.txt Comments: To: IESG Secretary Comments: cc: Alex Zinin , Bill Fenner To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42A9E0F9.1020902@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit The WG last call for the subject document has completed. It will now go to the IESG for review. Thanks, Acee Acee Lindem wrote: > This version of the draft attempts to satisfy Adrian Farrel's comments as > well as including an LSA definition for OSPFv3. At this point, I'd like > to re-last call it. > > All comments should be sent to this list by 12 AM (EDT), 06/24/2005. > > A URL for this Internet-Draft is: > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-07.txt > > There is (at least) one typo in the IANA considerations that I will > fix prior to queueing the document for IESG review. > Thanks, > Acee > > 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 : Extensions to OSPF for Advertising Optional Router >> Capabilities >> Author(s) : A. Lindem, et al. >> Filename : draft-ietf-ospf-cap-07.txt >> Pages : 14 >> Date : 2005-5-23 >> >> It is useful for routers in an OSPFv2 or OSPFv3 routing domain to >> know the capabilities of their neighbors and other routers in the >> routing domain. This draft proposes extensions to OSPFv2 and OSPFv3 >> for advertising optional router capabilities. A new Router >> Information (RI) LSA is proposed for this purpose. In OSPFv2, the RI >> LSA will be implemented with a new opaque LSA type ID. In OSPFv3, >> the RI LSA will be implemented with a new LSA type function code. In >> both protocols, the RI LSA can be advertised at any of the defined >> flooding scopes (link, area, or AS). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-07.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-cap-07.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-cap-07.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. >> ------------------------------------------------------------------------- >> >> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY >> ------------------------------------------------------------------------- >> >> In order to maintain computing infrastructure integrity, Cisco Systems >> Enterprise Messaging Services and InfoSec teams have set a mail policy >> disallowing executable attachments in email. >> >> This message contained an executable attachment type that is >> prohibited by this policy. The attachment has been removed from this >> message and copied to quarantine by our systems. It will be held in >> quarantine for >> seven days in the event that the content needs to be retrieved. >> >> Please be aware many viruses attempt to look like legitimate email or >> notifications from anti-virus systems. We will clearly mark a seperation >> between our notifications and the original email as follows: >> >> "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" >> >> For further reference information about viruses and email antivirus >> efforts within Cisco, please visit: >> >> http://wwwin.cisco.com/it/ems/services/antiviral >> >> If your concern isn't addressed by the information in this >> notification or the above web page, you may open a support request: >> >> http://wwwin.cisco.com/support/ >> >> Select "Messaging", "Email-Related", "Mail Routing" >> >> Please include in the text of your case the following information: >> >> * Full headers of the message. Documentation on displaying the full >> headers is available at this URL: >> >> http://wwwin.cisco.com/support/library/faqs/solution002471.html >> * This unique quarantine identifier: j4NJtp53013712 >> >> If the matter is urgent, you may follow up by calling one of the >> below referenced numbers. Please make every effort to provide the >> above requested information via the support web tool prior to calling >> as it will greatly aid the resolution of your issue. >> >> Americas: >> 1 408 526 8888 >> >> Asiapac >> +61 2 8446 8888 >> >> EMEA >> +31 20 485 4888 >> >> Japan >> +81 3 5549 6888 >> >> US (Toll Free) >> 1| 800| 888| 8187| (ext.68888) >> >> Thank you for your cooperation, >> >> Enterprise Messaging Services >> Cisco Systems, Inc >> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 01 10:35:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoMbm-0007oP-38 for ospf-archive@megatron.ietf.org; Fri, 01 Jul 2005 10:35:10 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00987 for ; Fri, 1 Jul 2005 10:35:06 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010957D8@cherry.ease.lsoft.com>; Fri, 1 Jul 2005 10:35:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77588340 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 1 Jul 2005 10:35:03 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 1 Jul 2005 10:35:03 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2005 07:35:05 -0700 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 j61EZ0ve028095; Fri, 1 Jul 2005 07:35:04 -0700 (PDT) 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, 1 Jul 2005 10:35:00 -0400 Received: from [10.82.217.175] ([10.82.217.175]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 10:34:59 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200505231945.PAA03257@ietf.org> <42A9E0F9.1020902@cisco.com> <42C5511C.4020407@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2005 14:35:00.0020 (UTC) FILETIME=[0F5A8F40:01C57E4A] Message-ID: <42C55494.3030505@cisco.com> Date: Fri, 1 Jul 2005 10:35:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-cap-07.txt Comments: To: IESG Secretary Comments: cc: Alex Zinin , Bill Fenner To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42C5511C.4020407@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > The WG last call for the subject document has completed. It will > now go to the IESG for review. The document category is Proposed Standard. > > Thanks, > Acee > > Acee Lindem wrote: > >> This version of the draft attempts to satisfy Adrian Farrel's >> comments as >> well as including an LSA definition for OSPFv3. At this point, I'd like >> to re-last call it. >> >> All comments should be sent to this list by 12 AM (EDT), 06/24/2005. >> >> A URL for this Internet-Draft is: >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-07.txt >> >> There is (at least) one typo in the IANA considerations that I will >> fix prior to queueing the document for IESG review. >> Thanks, >> Acee >> >> 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 : Extensions to OSPF for Advertising Optional >>> Router Capabilities >>> Author(s) : A. Lindem, et al. >>> Filename : draft-ietf-ospf-cap-07.txt >>> Pages : 14 >>> Date : 2005-5-23 >>> It is useful for routers in an OSPFv2 or OSPFv3 routing domain to >>> know the capabilities of their neighbors and other routers in the >>> routing domain. This draft proposes extensions to OSPFv2 and OSPFv3 >>> for advertising optional router capabilities. A new Router >>> Information (RI) LSA is proposed for this purpose. In OSPFv2, the RI >>> LSA will be implemented with a new opaque LSA type ID. In OSPFv3, >>> the RI LSA will be implemented with a new LSA type function code. In >>> both protocols, the RI LSA can be advertised at any of the defined >>> flooding scopes (link, area, or AS). >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-07.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-cap-07.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-cap-07.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. >>> ------------------------------------------------------------------------- >>> >>> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY >>> ------------------------------------------------------------------------- >>> >>> In order to maintain computing infrastructure integrity, Cisco Systems >>> Enterprise Messaging Services and InfoSec teams have set a mail policy >>> disallowing executable attachments in email. >>> >>> This message contained an executable attachment type that is >>> prohibited by this policy. The attachment has been removed from this >>> message and copied to quarantine by our systems. It will be held in >>> quarantine for >>> seven days in the event that the content needs to be retrieved. >>> >>> Please be aware many viruses attempt to look like legitimate email >>> or notifications from anti-virus systems. We will clearly mark a >>> seperation >>> between our notifications and the original email as follows: >>> >>> "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" >>> >>> For further reference information about viruses and email antivirus >>> efforts within Cisco, please visit: >>> >>> http://wwwin.cisco.com/it/ems/services/antiviral >>> >>> If your concern isn't addressed by the information in this >>> notification or the above web page, you may open a support request: >>> >>> http://wwwin.cisco.com/support/ >>> >>> Select "Messaging", "Email-Related", "Mail Routing" >>> >>> Please include in the text of your case the following information: >>> >>> * Full headers of the message. Documentation on displaying the full >>> headers is available at this URL: >>> >>> http://wwwin.cisco.com/support/library/faqs/solution002471.html >>> * This unique quarantine identifier: j4NJtp53013712 >>> >>> If the matter is urgent, you may follow up by calling one of the >>> below referenced numbers. Please make every effort to provide the >>> above requested information via the support web tool prior to >>> calling as it will greatly aid the resolution of your issue. >>> >>> Americas: >>> 1 408 526 8888 >>> >>> Asiapac >>> +61 2 8446 8888 >>> >>> EMEA >>> +31 20 485 4888 >>> >>> Japan >>> +81 3 5549 6888 >>> >>> US (Toll Free) >>> 1| 800| 888| 8187| (ext.68888) >>> >>> Thank you for your cooperation, >>> >>> Enterprise Messaging Services >>> Cisco Systems, Inc >>> >>> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 01 11:57:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoNtB-0006sZ-8B for ospf-archive@megatron.ietf.org; Fri, 01 Jul 2005 11:57:13 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09250 for ; Fri, 1 Jul 2005 11:57:10 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.01095DEB@cherry.ease.lsoft.com>; Fri, 1 Jul 2005 11:57:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77599262 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 1 Jul 2005 11:57:00 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 1 Jul 2005 11:57:00 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2005 08:56:59 -0700 X-IronPort-AV: i="3.93,250,1115017200"; d="scan'208"; a="646787657:sNHT28951168" 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 j61Fuvod019623 for ; Fri, 1 Jul 2005 08:56:57 -0700 (PDT) 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, 1 Jul 2005 11:56:58 -0400 Received: from [10.82.217.175] ([10.82.217.175]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 11:56:58 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <428F6453.7030405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2005 15:56:58.0895 (UTC) FILETIME=[833B51F0:01C57E55] Message-ID: <42C567C9.5030108@cisco.com> Date: Fri, 1 Jul 2005 11:56:57 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call for "Traffic Engineering Extensions to OSPF version 3" To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <428F6453.7030405@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit The WG Last Call for the subject document has completed. However, we are in the midst of some discussions as to whether or not we should attempt to satisfy some the Automatically Switched Optical Network (ASON) reqjuirements (Refer to draft-ietf-camp-gmpls-ason-routing-reqts-05.txt). I have some minor concerns with this. 1. While some of the ASON documents have gone through ccamp last calls, it still seems to me that the ink may be wet on the ASON requirements. 2. The proposed addition to OSPFv3 TE will satisfy the requirement to advertise TE information for multiple data plane elements (i.e., LSRs). However, there are other requirements (e.g., multi-level area hierachy) which are not satisfied. 3. This document is applicable to OSPFv3. However, we need a solution that applies to OSPFv2 as well. 4. If you accept #2, what about backward compatibiliy? Unknown TLV types are ignored so it would seem back compatible. However, this would have the undesirable side effect of associated TE information for all subordinate LSRs with the OSPF router. Hence, it seems at least one other new TLV will be required to advertise the new Router Address TLV for OSPFv2. #2 and #3 make me think we might be better off with a separate OSPF ASON document. Any other thoughts, Acee Acee Lindem wrote: > A couple weeks back I asked if anyone had any objections > to last calling this document. Heretofore, I have received > none. Also, I believe there is at least one commercially > available implementation. > > Hence, without further ado, this is the start of a > OSPF Working Group last call for: > > Traffic Engineering Extensions to OSPF version 3" > (draft-ietf-ospf-ospfv3-traffic-04.txt). > > All comments should be sent to this list by > 12 AM (EDT), 06/07/2005. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-05.txt > > Thanks, > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 05 00:24:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpeyX-0003ih-SE for ospf-archive@megatron.ietf.org; Tue, 05 Jul 2005 00:24:02 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12808 for ; Tue, 5 Jul 2005 00:23:59 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0109ACA9@cherry.ease.lsoft.com>; Tue, 5 Jul 2005 0:23:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77981506 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Jul 2005 00:23:56 -0400 Received: from 203.196.196.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Jul 2005 00:13:55 -0400 Received: from netd.com ([10.91.0.199]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id j654Feq3022117 for ; Tue, 5 Jul 2005 09:45:45 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 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-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <42CA0864.5050709@netd.com> Date: Tue, 5 Jul 2005 09:41:16 +0530 Reply-To: Mailing List Sender: Mailing List From: tajay Subject: OSPF : Summarization of type-7 lsa's To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit hi guys, I have some doubts and queries in NSSA. Whenever we use summarization in OSPF we generate only one type-5 lsa for all type-7 lsa's which falls under configured summary address. Now As per RFC 1587 / 3101 " The path type should always be set to the highest path type that is subsumed by the net range." Metric depends on path type , 1> If path type selected is external type 2 then type 5 metric should be set to the largest type-7 metric subsumed by this net range + 1 ; ****** I have doubt like.. why we add 1 in this cost ..Is there any specific reason behind this? 2> If the path type selected in external type 1 , the type -5 metric should be set to the largest metric.. *** In this case we don't add any cost to ASBR. why this is so? Can any one please give me guideline. thanks with regards ajay From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 05 19:47:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpx8R-0006pg-UZ for ospf-archive@megatron.ietf.org; Tue, 05 Jul 2005 19:47:28 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20803 for ; Tue, 5 Jul 2005 19:47:24 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0109BAB8@cherry.ease.lsoft.com>; Tue, 5 Jul 2005 19:47:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78095911 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Jul 2005 19:47:18 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Jul 2005 19:47:17 -0400 Received: from aksmtpmdr2 (ish3-internal [146.171.1.21]) by smtp3.telecom.co.nz (Postfix) with ESMTP id 6AA7F1F43 for ; Wed, 6 Jul 2005 11:41:24 +1200 (NZST) Received: from 146.171.227.24 by aksmtpmdr2 with ESMTP (Tumbleweed MMS SMTP Relay); Wed, 06 Jul 2005 11:47:03 +1200 X-Server-Uuid: 39C90538-1505-4F6D-9FBD-402FA253957C Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp01.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 11:46:53 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Wed, 6 Jul 2005 09:46:50 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Thread-Topic: Two queries on calculating AS external routes thread-index: AcV76aPtnSPKc9Z9Rkq/HCBn4jxwdAASNM4AAWIBhuA= X-OriginalArrivalTime: 05 Jul 2005 23:46:50.0396 (UTC) FILETIME=[D053FDC0:01C581BB] X-WSS-ID: 6ED5C4651HG7374675-20-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB406824@aunswa002.au.tcnz.net> Date: Wed, 6 Jul 2005 09:43:21 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, Just been going through RFC3101 section 2.5. The tie-breaker rules seem=20 to apply if the LSAs being compared are functionally equivalent (including the same non-zero forwarding address). In my case below, what if the two=20 LSAs are not quite functoinally equivalent i.e what if the LSAs have the = same=20 destination, same cost etc but have different non-zero forwarding addresses= = =3F What happens then =3F Do the same tie-breaker rules apply or will it be=20 implementation-dependent =3F Thanks, Paresh. -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Paresh Khatri Sent: Wednesday, 29 June 2005 08:42 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Two queries on calculating AS external routes Thanks Acee, I guess that's the bit I was missing. Regards, Paresh. -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Tuesday, 28 June 2005 11:59 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Two queries on calculating AS external routes Paresh Khatri wrote: >Thanks Acee, > >Looking back at my second query, I realise that I wasn't quite clear on = what I was getting at (my apologies). It should be phrased as such: > >2) >Looking at step (6) now. If we have two, and only two, paths to a >destination N, with the following characteristics:=20 > - same route-type (say, Type 2 external)=20 > - same type-2 metric > - originated by two different ASBRs and the ASBRs are in different = non-backbone areas. > - the intra-area distance to the ASBR is the same for both paths (but of = course, through a > different area in each case) >Will both paths be installed in the routing table =3F If so, would that = not >contradict section 16.8, which states that all equal-cost paths for a route >should be associated with the same area =3F > >Would 16.4 (3) apply in this case or is it only applicable when you have = multiple paths to the *same* ASBR =3F > =20 > Hi Paresh, Although not explicitly stated, the intent of the RFC is to have a=20 single exit point =66rom the OSPF routing domain for the AS external route. This was=20 clarified in the latest NSSA RFC with the LSA with the highest router ID given preference=20 - see section 2.5 of RFC 3101. Hope this helps, Acee >Thanks again, >Paresh. > > =20 > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee >Lindem >Sent: Tuesday, 28 June 2005 12:18 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Two queries on calculating AS external routes > > >Hi Paresh, >See inline. > >Paresh Khatri wrote: > > =20 > >>Hi all, >> >>I've got a couple of queries on Section 16.4 of RFC2328 that I hope = someone >>can help me with. >> >>1) >>When determining that preferred routing table entry for the ASBR in step >>(4), what happens if we end up with two equal-cost intra-area routes (for >>the same area) to the ASBR (this is after all the pruning from 16.4.1 etc= )= =3F >>Will both routes be installed in the routing table =3F >>=20 >> >> =20 >> >Yes. Both paths should both be installed. > > =20 > >>2) >> >>Looking at step (6) now. If we have two, and only two, paths to a >>destination N, with the following characteristics:=20 >>- same route-type (say, Type 2 external)=20 >>- same type-2 metric >>- both are intra-area routes but for different non-backbone areas ( so we >>still end up with 2 paths after 16.4.1) >>- the intra-area distance to the ASBR is the same for both paths >>Will both paths be installed in the routing table =3F If so, would that = not >>contradict section 16.8, which states that all equal-cost paths for a = route >>should be associated with the same area =3F >>=20 >> >> =20 >> >For equal cost paths to an ASBR, the path through the area with the=20 >highest ID should be >chosen (refer to 16.4 (3)). > >Hope this helps, >Acee > > =20 > >>All responses appreciated. >> >>Cheers, >>Paresh Khatri=20 >> >>=20 >> >> =20 >> > > > > > >This communication, including any attachments, is confidential. If=20 > you are not the intended recipient, you should not read it - please=20 > contact me immediately, destroy it, and do not copy or use any part of=20 > this communication or disclose anything about it. > > =20 > This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 05 19:56:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpxH1-0002up-31 for ospf-archive@megatron.ietf.org; Tue, 05 Jul 2005 19:56:19 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21753 for ; Tue, 5 Jul 2005 19:56:16 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0109B9B9@cherry.ease.lsoft.com>; Tue, 5 Jul 2005 19:56:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78096670 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Jul 2005 19:56:16 -0400 Received: from 64.233.184.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Jul 2005 19:56:16 -0400 Received: by wproxy.gmail.com with SMTP id 67so1131863wri for ; Tue, 05 Jul 2005 16:56:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Zqrf05DNp8oZK4mAyh+olCGS7zkfQU8nB7W6dKl+zVEtN3j0raxXmDKRf4NFdWGAZOslHwAiVXNo2YVrSJA//KMeaT1NPL2pG4844kV8f7Xjk0XMNc946o8BEw+jRU0SqciPZUe+I4fiQbWXinvTLKqDw8VGdMP6TgpDa+kvwLw= Received: by 10.54.45.21 with SMTP id s21mr4788779wrs; Tue, 05 Jul 2005 16:56:16 -0700 (PDT) Received: by 10.54.43.45 with HTTP; Tue, 5 Jul 2005 16:56:16 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: Date: Tue, 5 Jul 2005 16:56:16 -0700 Reply-To: Mailing List Sender: Mailing List From: Dilip Kumar Subject: RFC-3630: Router Address TLV To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, I would like to know if Router Address TLV's value field MUST contain a syntatically correct IP Address. I mean, is it OK if an OSPF router advertises Opaque LSA (TE) with an syntatically incorrect IP address (ex. 0.0.0.54 etc.) in Router Address TLV ? Thanks, Dilip From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 06 06:21:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq72G-0004Li-MI for ospf-archive@megatron.ietf.org; Wed, 06 Jul 2005 06:21:44 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18968 for ; Wed, 6 Jul 2005 06:21:42 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0109C472@cherry.ease.lsoft.com>; Wed, 6 Jul 2005 6:21:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78155581 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Jul 2005 06:21:41 -0400 Received: from 203.199.83.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Jul 2005 06:21:40 -0400 Received: (qmail 12424 invoked by uid 510); 6 Jul 2005 10:23:08 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 06 jul 2005 10:23:08 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1120645388---0-203.199.83.135-12416" Message-ID: <20050706102308.12423.qmail@webmail45.rediffmail.com> Date: Wed, 6 Jul 2005 10:23:08 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: draft-ietf-ospf-ospfv3-mib-09 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1120645388---0-203.199.83.135-12416 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable No configuration support is provided for "ospfRFC1583Compatibility " in OSP= Fv3?=0A=0AThanks=0AVivek=0A=0A=0A=0A=0AOn Wed, 06 Jul 2005 Dilip Kumar wrot= e :=0A>Hi,=0A> I would like to know if Router Address TLV's value field= MUST=0A>contain a syntatically correct IP Address. I mean, is it OK if an = OSPF=0A>router advertises Opaque LSA (TE) with an syntatically incorrect IP= =0A>address (ex. 0.0.0.54 etc.) in Router Address TLV ?=0A>=0A>Thanks,=0A>D= ilip=0A --Next_1120645388---0-203.199.83.135-12416 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0ANo configuration support is provided for "ospfRFC1583Compatibili= ty " in OSPFv3?
=0A
=0AThanks
=0AVivek
=0A
=0A
=0A=0A
=0AOn Wed, 06 Jul 2005 Dilip Kumar wrote :
=0A>Hi,
=0A>= ;    I would like to know if Router Address TLV's value field MU= ST
=0A>contain a syntatically correct IP Address. I mean, is it OK if= an OSPF
=0A>router advertises Opaque LSA (TE) with an syntatically i= ncorrect IP
=0A>address (ex. 0.0.0.54 etc.) in Router Address TLV ?=0A>
=0A>Thanks,
=0A>Dilip
=0A=0A

=0A

=0A=0A --Next_1120645388---0-203.199.83.135-12416-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 06 06:30:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7B7-00031Q-W3 for ospf-archive@megatron.ietf.org; Wed, 06 Jul 2005 06:30:54 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20688 for ; Wed, 6 Jul 2005 06:30:51 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0109C343@cherry.ease.lsoft.com>; Wed, 6 Jul 2005 6:30:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78159441 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Jul 2005 06:30:51 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Jul 2005 06:30:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-mib-09 Thread-Index: AcWCFIHmB/pvim1dQxWcchEsbEmmUQAAEQWw Message-ID: Date: Wed, 6 Jul 2005 03:31:04 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-mib-09 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Vivek, Is there a reason we need to support compatibility with an older version = of OSPFv2 (RFC1583) in OSPFv3? Regarding a previous mail of yours "ospfv3AreaSummary: The variable should also effect NSSA areas. = Description should be updated" We will update the description to also state NSSA (to be consistent with = OSPFv2 MIB). Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek = Dubey Sent: Wednesday, July 06, 2005 3:53 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: draft-ietf-ospf-ospfv3-mib-09 No configuration support is provided for "ospfRFC1583Compatibility " in = OSPFv3? Thanks Vivek On Wed, 06 Jul 2005 Dilip Kumar wrote : >Hi, >=A0 =A0 I would like to know if Router Address TLV's value field MUST >contain a syntatically correct IP Address. I mean, is it OK if an OSPF >router advertises Opaque LSA (TE) with an syntatically incorrect IP >address (ex. 0.0.0.54 etc.) in Router Address TLV ? > >Thanks, >Dilip From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 07 04:47:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqS2v-0000HO-Lw for ospf-archive@megatron.ietf.org; Thu, 07 Jul 2005 04:47:51 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12914 for ; Thu, 7 Jul 2005 04:47:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0109D5F0@cherry.ease.lsoft.com>; Thu, 7 Jul 2005 4:47:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78194461 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Jul 2005 04:47:42 -0400 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Jul 2005 04:47:41 -0400 Received: (qmail 21677 invoked by uid 510); 7 Jul 2005 08:49:09 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 07 jul 2005 08:49:08 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1120726148---0-203.199.83.148-21667" Message-ID: <20050707084909.21675.qmail@webmail26.rediffmail.com> Date: Thu, 7 Jul 2005 08:49:09 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: draft-ietf-ospf-ospfv3-mib-09 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1120726148---0-203.199.83.148-21667 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Vishwas,=0AReason why i mentioned "ospfRFC1583Compatibility"=0A=0Adraft-= ietf-ospf-ospfv3-update-04.txt=0A3.8.5 Calculating AS external routes=0A--= ------------------------------------=0AThe IPv6 AS external route calculati= on proceeds along the same lines=0Aas the IPv4 calculation in Section 16.4 = of [OSPFV2] and Section 2.5=0Aof [NSSA], with the following exceptions:=0A= =0A It is not listed in exceptions and RFC2328 Section 16.4 has=0Ath= e description. =0A=0AThanks=0AVivek=0A=0A=0A=0AOn Wed, 06 Jul 2005 Vishwas = Manral wrote :=0A>Hi Vivek,=0A>=0A>Is there a reason we need to support com= patibility with an older version of OSPFv2 (RFC1583) in OSPFv3?=0A>=0A>Rega= rding a previous mail of yours=0A>"ospfv3AreaSummary: The variable should a= lso effect NSSA areas. Description should be updated"=0A>We will update the= description to also state NSSA (to be consistent with OSPFv2 MIB).=0A>=0A>= Thanks,=0A>Vishwas=0A>________________________________________=0A> From: Ma= iling List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek Dubey=0A>S= ent: Wednesday, July 06, 2005 3:53 PM=0A>To: OSPF@PEACH.EASE.LSOFT.COM=0A>S= ubject: draft-ietf-ospf-ospfv3-mib-09=0A>=0A>No configuration support is pr= ovided for "ospfRFC1583Compatibility " in OSPFv3?=0A>=0A>Thanks=0A>Vivek=0A= >=0A>=0A>=0A>=0A>On Wed, 06 Jul 2005 Dilip Kumar wrote :=0A> >Hi,=0A> >=A0 = =A0 I would like to know if Router Address TLV's value field MUST=0A> >cont= ain a syntatically correct IP Address. I mean, is it OK if an OSPF=0A> >rou= ter advertises Opaque LSA (TE) with an syntatically incorrect IP=0A> >addre= ss (ex. 0.0.0.54 etc.) in Router Address TLV ?=0A> >=0A> >Thanks,=0A> >Dili= p=0A --Next_1120726148---0-203.199.83.148-21667 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi Vishwas,
=0AReason why i mentioned "ospfRFC1583Compatibili= ty"
=0A
=0Adraft-ietf-ospf-ospfv3-update-04.txt
=0A3.8.5 = ; Calculating AS external routes
=0A------------------------------------= --
=0AThe IPv6 AS external route calculation proceeds along the same lin= es
=0Aas the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.= 5
=0Aof [NSSA], with the following exceptions:
=0A
=0A<vivek>= ; It is not listed in exceptions and RFC2328 Section 16.4 has
=0Athe des= cription.
=0A
=0AThanks
=0AVivek
=0A
=0A
=0A
=0AOn We= d, 06 Jul 2005 Vishwas Manral wrote :
=0A>Hi Vivek,
=0A>
=0A= >Is there a reason we need to support compatibility with an older versio= n of OSPFv2 (RFC1583) in OSPFv3?
=0A>
=0A>Regarding a previous = mail of yours
=0A>"ospfv3AreaSummary: The variable should also e= ffect NSSA areas. Description should be updated"
=0A>We will upd= ate the description to also state NSSA (to be consistent with OSPFv2 MIB).<= BR>=0A>
=0A>Thanks,
=0A>Vishwas
=0A>__________________= ______________________
=0A> From: Mailing List [mailto:OSPF@PEACH.EAS= E.LSOFT.COM] On Behalf Of Vivek Dubey
=0A>Sent: Wednesday, July 06, 2= 005 3:53 PM
=0A>To: OSPF@PEACH.EASE.LSOFT.COM
=0A>Subject: draf= t-ietf-ospf-ospfv3-mib-09
=0A>
=0A>No configuration support is = provided for "ospfRFC1583Compatibility " in OSPFv3?
=0A>=0A>Thanks
=0A>Vivek
=0A>
=0A>
=0A>
=0A><= BR>=0A>On Wed, 06 Jul 2005 Dilip Kumar wrote :
=0A> >Hi,
=0A= > >    I would like to know if Router Address TLV's value f= ield MUST
=0A> >contain a syntatically correct IP Address. I mean,= is it OK if an OSPF
=0A> >router advertises Opaque LSA (TE) with = an syntatically incorrect IP
=0A> >address (ex. 0.0.0.54 etc.) in = Router Address TLV ?
=0A> >
=0A> >Thanks,
=0A> >= Dilip
=0A=0A

=0A

=0A=0A --Next_1120726148---0-203.199.83.148-21667-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 07 10:47:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXfP-0000tD-5S for ospf-archive@megatron.ietf.org; Thu, 07 Jul 2005 10:47:57 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14001 for ; Thu, 7 Jul 2005 10:47:49 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0109DAF2@cherry.ease.lsoft.com>; Thu, 7 Jul 2005 10:47:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78251439 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Jul 2005 10:47:44 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Jul 2005 10:47:44 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01LQC49EC9G8003LOZ@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 07 Jul 2005 07:50:51 -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: <01LQC49ECAE2003LOZ@omega7.wr.usgs.gov> Date: Thu, 7 Jul 2005 07:50:51 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: OSPF : Summarization of type-7 lsa's To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Ajay, > 1> If path type selected is external type 2 then type 5 metric >should be set to the largest type-7 metric subsumed by this net range + >1 ; >****** I have doubt like.. why we add 1 in this cost ..Is there any >specific reason behind this? The only hint comes from RFC 1587/3101 wording These metric and path type rules will avoid routing loops in the event that path type 1 and 2 are both used within the area. I believe this was done in RFC 1587 to distinguish the Type-5 LSA originated via the Type-7 translation/summarization process from a Type-7 LSA that has the same prefix. However this is conjecture on my part and I don't ever remember verifying it in a discussion with Rob Coltun. A tight routing loop seems possible in this case when the tie breaker rules of RFC 1587's external route calculation Step 5 are applied: a. Any type 5 LSA. b. A type-7 LSA with the P-bit set and the forwarding address non-zero. c. Any other type-7 LSA. An NSSA would need two ABRs and the translator would have to see an NSSA path to the Type-7 LSA's prefix through the second ABR for the loop to occur. The RFC 3101 tie breaker rules deal with this situation completely differently, and it is possible that adding +1 is no longer necessary. I realized this once, but adding +1 to the type 2 computed metric appeared harmless enough that a change seemed unwarranted. I do have a minor correction to make to RFC 3101 from an earlier disuccsion, so if the current WG feels this should be changed I have no objections. >2> If the path type selected in external type 1 , the type -5 metric >should be set to the largest metric.. >*** In this case we don't add any cost to ASBR. why this is so? The distance to the originator of the type-7 LSA plays a role in computing the translated Type 5's type 1 metric. Hence the second ABR above would compute a more preferred path via the Type-7 LSA that does not go through the translator ABR Pat From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 07 11:10:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqY15-0004RB-Vr for ospf-archive@megatron.ietf.org; Thu, 07 Jul 2005 11:10:20 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16113 for ; Thu, 7 Jul 2005 11:10:15 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0109DE03@cherry.ease.lsoft.com>; Thu, 7 Jul 2005 11:10:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78253305 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Jul 2005 11:10:15 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Jul 2005 11:10:14 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01LQC519TT68003LOZ@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 07 Jul 2005 08:13:19 -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: <01LQC519TT6A003LOZ@omega7.wr.usgs.gov> Date: Thu, 7 Jul 2005 08:13:19 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Paresh, >In my case below, what if the two LSAs are not quite >functoinally equivalent i.e what if the LSAs have the same >destination, same cost etc but have different non-zero >forwarding addresses ? What happens then ? Do the same >tie-breaker rules apply or will it be implementation-dependent ? The tie breaker rules are not applied. Here the installation decision process is the same regardless of whether it is comparing two Type 5 LSAs, or a Type 5 and a Type 7 LSA, or two Type 7 LSAs. Whether or not both are installed depends on the pruning done in step (c) as defined in RFC 2328 Section 16.4.1. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 08 05:53:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqpXq-0008Ch-4L for ospf-archive@megatron.ietf.org; Fri, 08 Jul 2005 05:53:18 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15993 for ; Fri, 8 Jul 2005 05:53:15 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0109ED74@cherry.ease.lsoft.com>; Fri, 8 Jul 2005 5:53:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78330316 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Jul 2005 05:53:13 -0400 Received: from 203.196.196.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 8 Jul 2005 05:53:12 -0400 Received: from netd.com ([10.91.0.11]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id j689suq3015170 for ; Fri, 8 Jul 2005 15:25:02 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01LQC49ECAE2003LOZ@omega7.wr.usgs.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <42CE4C55.5010707@netd.com> Date: Fri, 8 Jul 2005 15:20:13 +0530 Reply-To: Mailing List Sender: Mailing List From: tajay Subject: Re: OSPF : Summarization of type-7 lsa's To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01LQC49ECAE2003LOZ@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit murthy, thanks for answering my queries. I have some more queries in OSPF - NSSA area. Suppose i have configured summary-address to summarize more than one type-7 lsa. In this case we while generating type-5 lsa we follow section 4.1 of rfc 1587 . e.g. 1> If none of the lsa's LS-Id matches to my summary-address range but LS-Id falls under configured summary address range, then we generate type-5 as per rfc 1587 -section 4.1 (2) and 2> If my LSA has LS-Id equal to summary address range then we generate type-5 lsa as per rfc 1587 section-4.1(1) What happens if ospf database has one LSA with LS-Id matches to my summary-address range and some LSAs with LS-Id falling under summary-address range. Then in this case what type of metric or path-type we should set in the type-5 lsa? with regards ajay Pat Murphy - (650)329-4044 wrote: >Ajay, > > > >> 1> If path type selected is external type 2 then type 5 metric >>should be set to the largest type-7 metric subsumed by this net range + >>1 ; >> >> > > > >>****** I have doubt like.. why we add 1 in this cost ..Is there any >>specific reason behind this? >> >> > >The only hint comes from RFC 1587/3101 wording > > These metric and path type rules will avoid routing > loops in the event that path type 1 and 2 are both > used within the area. > >I believe this was done in RFC 1587 to distinguish the Type-5 LSA >originated via the Type-7 translation/summarization process from a >Type-7 LSA that has the same prefix. However this is conjecture on my >part and I don't ever remember verifying it in a discussion with Rob >Coltun. A tight routing loop seems possible in this case when the tie >breaker rules of RFC 1587's external route calculation Step 5 are >applied: > > a. Any type 5 LSA. > b. A type-7 LSA with the P-bit set and the forwarding > address non-zero. > c. Any other type-7 LSA. > >An NSSA would need two ABRs and the translator would have to see an NSSA >path to the Type-7 LSA's prefix through the second ABR for the loop to >occur. > >The RFC 3101 tie breaker rules deal with this situation completely >differently, and it is possible that adding +1 is no longer necessary. I >realized this once, but adding +1 to the type 2 computed metric appeared >harmless enough that a change seemed unwarranted. I do have a minor >correction to make to RFC 3101 from an earlier disuccsion, so if the >current WG feels this should be changed I have no objections. > > > >>2> If the path type selected in external type 1 , the type -5 metric >>should be set to the largest metric.. >> >> > > > >>*** In this case we don't add any cost to ASBR. why this is so? >> >> > >The distance to the originator of the type-7 LSA plays a role in >computing the translated Type 5's type 1 metric. Hence the second ABR >above would compute a more preferred path via the Type-7 LSA that does >not go through the translator ABR > >Pat > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 08 06:49:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqqQT-0003g3-3V for ospf-archive@megatron.ietf.org; Fri, 08 Jul 2005 06:49:45 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19430 for ; Fri, 8 Jul 2005 06:49:42 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0109ECE7@cherry.ease.lsoft.com>; Fri, 8 Jul 2005 6:49:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78366586 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Jul 2005 06:49:28 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 8 Jul 2005 06:49:28 -0400 Received: from aksmtpmdr2 (ish3-internal [146.171.1.21]) by smtp3.telecom.co.nz (Postfix) with ESMTP id 220461F37 for ; Fri, 8 Jul 2005 22:43:32 +1200 (NZST) Received: from 146.171.227.25 by aksmtpmdr2 with ESMTP (Tumbleweed MMS SMTP Relay); Fri, 08 Jul 2005 22:49:15 +1200 X-Server-Uuid: 39C90538-1505-4F6D-9FBD-402FA253957C Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp02.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 22:49:14 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Fri, 8 Jul 2005 20:49:14 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 MIME-Version: 1.0 X-MS-TNEF-Correlator: <44CF9D8D25966C4DB1072958419273DB406826@aunswa002.au.tcnz.net> Thread-Topic: RFC-3630: Router Address TLV thread-index: AcWBvSnjeIYfmcewRvagdrEmd8DriQB67EDG X-OriginalArrivalTime: 08 Jul 2005 10:49:14.0411 (UTC) FILETIME=[AE6EE7B0:01C583AA] X-WSS-ID: 6ED085A11HG7930253-01-01 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB406826@aunswa002.au.tcnz.net> Date: Fri, 8 Jul 2005 20:49:14 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Query on RFC1793 (OSPF over demain circuits) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi all, I'm trying to understand the example in Section 2.5 - Interoperability with= = unmodified OSPF routers. =20 The example states that router B (a non-DC capable router) will treat = DoNotAge LSAs as MaxAge LSAs and will acknowledge them as such to router A.= = But router A will notice that the ack is for a different instance and will= = re-transmit the LSA. My question is - why would router A consider it to be= = an ack for a different instance =3F Is the implication here that router B = would set the Age in the LSAck to be MaxAge and not the Age that was presen= t= in the received LSA =3F Thanks in advance. Paresh This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 08 09:07:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqsZT-0001GD-Hd for ospf-archive@megatron.ietf.org; Fri, 08 Jul 2005 09:07:15 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29820 for ; Fri, 8 Jul 2005 09:07:10 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0109EF00@cherry.ease.lsoft.com>; Fri, 8 Jul 2005 9:07:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78376602 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Jul 2005 09:07:07 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 8 Jul 2005 09:07:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C583BD.F0D5616A" Thread-Topic: draft-ietf-ospf-ospfv3-mib-09 Thread-Index: AcWC0IxxM5suhTGVTqy5QJCRTKSf3QA7UDyw Message-ID: Date: Fri, 8 Jul 2005 06:07:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-mib-09 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C583BD.F0D5616A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Acee, =20 Should we list the below as an exception too in the OSPFv3 update draft? =20 Thanks, Vishwas ________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek Dubey Sent: Thursday, July 07, 2005 2:19 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-mib-09 =20 Hi Vishwas, Reason why i mentioned "ospfRFC1583Compatibility" draft-ietf-ospf-ospfv3-update-04.txt 3.8.5 Calculating AS external routes -------------------------------------- The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 of [NSSA], with the following exceptions: It is not listed in exceptions and RFC2328 Section 16.4 has the description.=20 Thanks Vivek On Wed, 06 Jul 2005 Vishwas Manral wrote : >Hi Vivek, > >Is there a reason we need to support compatibility with an older version of OSPFv2 (RFC1583) in OSPFv3? > >Regarding a previous mail of yours >"ospfv3AreaSummary: The variable should also effect NSSA areas. Description should be updated" >We will update the description to also state NSSA (to be consistent with OSPFv2 MIB). > >Thanks, >Vishwas >________________________________________ > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek Dubey >Sent: Wednesday, July 06, 2005 3:53 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: draft-ietf-ospf-ospfv3-mib-09 > >No configuration support is provided for "ospfRFC1583Compatibility " in OSPFv3? > >Thanks >Vivek > > > > >On Wed, 06 Jul 2005 Dilip Kumar wrote : > >Hi, > > I would like to know if Router Address TLV's value field MUST > >contain a syntatically correct IP Address. I mean, is it OK if an OSPF > >router advertises Opaque LSA (TE) with an syntatically incorrect IP > >address (ex. 0.0.0.54 etc.) in Router Address TLV ? > > > >Thanks, > >Dilip =20 ------_=_NextPart_001_01C583BD.F0D5616A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Acee,

 

Should we list the below as an = exception too in the OSPFv3 update draft?

 

Thanks,

=

Vishwas

=

From: = Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek Dubey
Sent: Thursday, July 07, = 2005 2:19 PM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: draft-ietf-ospf-ospfv3-mib-09

 

Hi Vishwas,
Reason why i mentioned "ospfRFC1583Compatibility"

draft-ietf-ospf-ospfv3-update-04.txt
3.8.5  Calculating AS external routes
--------------------------------------
The IPv6 AS external route calculation proceeds along the same lines
as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5
of [NSSA], with the following exceptions:

<vivek> It is not listed in exceptions and RFC2328 Section 16.4 = has
the description.

Thanks
Vivek



On Wed, 06 Jul 2005 Vishwas Manral wrote :
>Hi Vivek,
>
>Is there a reason we need to support compatibility with an older = version of OSPFv2 (RFC1583) in OSPFv3?
>
>Regarding a previous mail of yours
>"ospfv3AreaSummary: The variable should also effect NSSA areas. Description should be updated"
>We will update the description to also state NSSA (to be consistent = with OSPFv2 MIB).
>
>Thanks,
>Vishwas
>________________________________________
> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of = Vivek Dubey
>Sent: Wednesday, July 06, 2005 3:53 PM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: draft-ietf-ospf-ospfv3-mib-09
>
>No configuration support is provided for = "ospfRFC1583Compatibility " in OSPFv3?
>
>Thanks
>Vivek
>
>
>
>
>On Wed, 06 Jul 2005 Dilip Kumar wrote :
> >Hi,
> >    I would like to know if Router Address TLV's = value field MUST
> >contain a syntatically correct IP Address. I mean, is it OK if = an OSPF
> >router advertises Opaque LSA (TE) with an syntatically = incorrect IP
> >address (ex. 0.0.0.54 etc.) in Router Address TLV ?
> >
> >Thanks,
> >Dilip



------_=_NextPart_001_01C583BD.F0D5616A-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jul 09 12:34:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrII7-0004Iq-48 for ospf-archive@megatron.ietf.org; Sat, 09 Jul 2005 12:34:59 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10556 for ; Sat, 9 Jul 2005 12:34:55 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010A0329@cherry.ease.lsoft.com>; Sat, 9 Jul 2005 12:34:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78495579 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 9 Jul 2005 12:34:50 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 9 Jul 2005 12:34:50 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2005 09:34:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,276,1115017200"; d="scan'208"; a="1126657:sNHT23751924" 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 j69GYok6010303 for ; Sat, 9 Jul 2005 12:34:50 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Jul 2005 12:34:51 -0400 Received: from [10.82.241.216] ([10.82.241.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Jul 2005 12:34:50 -0400 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: 09 Jul 2005 16:34:50.0155 (UTC) FILETIME=[205017B0:01C584A4] Message-ID: <42CFFCA9.5040500@cisco.com> Date: Sat, 9 Jul 2005 12:34:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-mib-09 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas Manral wrote: >Hi Acee, > > > >Should we list the below as an exception too in the OSPFv3 update draft? > > Hi Vishwas, Yes - I will add it in the next revision. Thanks, Acee > > >Thanks, > >Vishwas > >________________________________ > >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek >Dubey >Sent: Thursday, July 07, 2005 2:19 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: draft-ietf-ospf-ospfv3-mib-09 > > > >Hi Vishwas, >Reason why i mentioned "ospfRFC1583Compatibility" > >draft-ietf-ospf-ospfv3-update-04.txt >3.8.5 Calculating AS external routes >-------------------------------------- >The IPv6 AS external route calculation proceeds along the same lines >as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 >of [NSSA], with the following exceptions: > > It is not listed in exceptions and RFC2328 Section 16.4 has >the description. > >Thanks >Vivek > > > >On Wed, 06 Jul 2005 Vishwas Manral wrote : > > >>Hi Vivek, >> >>Is there a reason we need to support compatibility with an older >> >> >version of OSPFv2 (RFC1583) in OSPFv3? > > >>Regarding a previous mail of yours >>"ospfv3AreaSummary: The variable should also effect NSSA areas. >> >> >Description should be updated" > > >>We will update the description to also state NSSA (to be consistent >> >> >with OSPFv2 MIB). > > >>Thanks, >>Vishwas >>________________________________________ >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> >> >Vivek Dubey > > >>Sent: Wednesday, July 06, 2005 3:53 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: draft-ietf-ospf-ospfv3-mib-09 >> >>No configuration support is provided for "ospfRFC1583Compatibility " in >> >> >OSPFv3? > > >>Thanks >>Vivek >> >> >> >> >>On Wed, 06 Jul 2005 Dilip Kumar wrote : >> >> >>>Hi, >>> I would like to know if Router Address TLV's value field MUST >>>contain a syntatically correct IP Address. I mean, is it OK if an >>> >>> >OSPF > > >>>router advertises Opaque LSA (TE) with an syntatically incorrect IP >>>address (ex. 0.0.0.54 etc.) in Router Address TLV ? >>> >>>Thanks, >>>Dilip >>> >>> > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jul 09 13:15:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrIvY-0004m1-2W for ospf-archive@megatron.ietf.org; Sat, 09 Jul 2005 13:15:44 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12787 for ; Sat, 9 Jul 2005 13:15:40 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010A02AA@cherry.ease.lsoft.com>; Sat, 9 Jul 2005 13:15:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78497122 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 9 Jul 2005 13:15:36 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 9 Jul 2005 13:15:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2005 10:15:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,276,1115017200"; d="scan'208"; a="1129160:sNHT20379228" 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 j69HFak6016411 for ; Sat, 9 Jul 2005 13:15:36 -0400 (EDT) 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); Sat, 9 Jul 2005 13:15:37 -0400 Received: from [10.82.241.216] ([10.82.241.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Jul 2005 13:15:36 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01LQC519TT6A003LOZ@omega7.wr.usgs.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2005 17:15:36.0630 (UTC) FILETIME=[D2868D60:01C584A9] Message-ID: <42D00638.50108@cisco.com> Date: Sat, 9 Jul 2005 13:15:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01LQC519TT6A003LOZ@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat Murphy - (650)329-4044 wrote: >Paresh, > > > >>In my case below, what if the two LSAs are not quite >>functoinally equivalent i.e what if the LSAs have the same >>destination, same cost etc but have different non-zero >>forwarding addresses ? What happens then ? Do the same >>tie-breaker rules apply or will it be implementation-dependent ? >> >> > >The tie breaker rules are not applied. Here the installation >decision process is the same regardless of whether it is >comparing two Type 5 LSAs, or a Type 5 and a Type 7 LSA, or two >Type 7 LSAs. Whether or not both are installed depends on the >pruning done in step (c) as defined in RFC 2328 Section 16.4.1. > > Conceivably, you still could end up with LSAs with differing forwarding addresses of equal cost and equivalent path preference for the prefix. I don't believe this case is covered. However, since the forwarding address costs are equal, I don't think there should be any loops. >Pat > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jul 10 07:11:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrZiI-0004Mr-QG for ospf-archive@megatron.ietf.org; Sun, 10 Jul 2005 07:11:10 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23888 for ; Sun, 10 Jul 2005 07:11:07 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010A0BEA@cherry.ease.lsoft.com>; 10 Jul 2005 7:11:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78573398 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 10 Jul 2005 07:10:28 -0400 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 10 Jul 2005 07:10:27 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 10 Jul 2005 04:10:23 -0700 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 j6ABAIod025139 for ; Sun, 10 Jul 2005 04:10:18 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 07:10:22 -0400 Received: from [10.82.241.216] ([10.82.241.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 07:10:22 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <44CF9D8D25966C4DB1072958419273DB406826@aunswa002.au.tcnz.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2005 11:10:22.0224 (UTC) FILETIME=[F6EF5100:01C5853F] Message-ID: <42D10208.1020802@cisco.com> Date: Sun, 10 Jul 2005 07:10:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Query on RFC1793 (OSPF over demain circuits) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <44CF9D8D25966C4DB1072958419273DB406826@aunswa002.au.tcnz.net> Precedence: list Content-Transfer-Encoding: 7bit Paresh Khatri wrote: >Hi all, > > Hi Paresh, >I'm trying to understand the example in Section 2.5 - Interoperability with unmodified OSPF routers. > >The example states that router B (a non-DC capable router) will treat DoNotAge LSAs as MaxAge LSAs and will acknowledge them as such to router A. But router A will notice that the ack is for a different instance and will re-transmit the LSA. My question is - why would router A consider it to be an ack for a different instance ? Is the implication here that router B would set the Age in the LSAck to be MaxAge and not the Age that was present in the received LSA ? > > Yes - note that the example is prefaced with "At the very worst". Acee >Thanks in advance. > >Paresh > > > > >This communication, including any attachments, is confidential. If > you are not the intended recipient, you should not read it - please > contact me immediately, destroy it, and do not copy or use any part of > this communication or disclose anything about it. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jul 10 19:47:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrlWR-0006D0-As for ospf-archive@megatron.ietf.org; Sun, 10 Jul 2005 19:47:43 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02711 for ; Sun, 10 Jul 2005 19:47:39 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010A106D@cherry.ease.lsoft.com>; 10 Jul 2005 19:47:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78608998 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 10 Jul 2005 19:47:38 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 10 Jul 2005 19:47:38 -0400 Received: from aksmtpmdr1 (ish2-internal [146.171.1.20]) by smtp3.telecom.co.nz (Postfix) with ESMTP id 66C171E50 for ; Mon, 11 Jul 2005 11:41:39 +1200 (NZST) Received: from 146.171.227.24 by aksmtpmdr1 with ESMTP (Tumbleweed MMS SMTP Relay); Mon, 11 Jul 2005 11:47:29 +1200 X-Server-Uuid: 50880B64-500D-4147-A4F0-826C22747D83 Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp01.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:47:29 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Mon, 11 Jul 2005 09:47:29 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Thread-Topic: Query on RFC1793 (OSPF over demain circuits) thread-index: AcWFQBqz1q2SXTpRSyWPu3n8cY6/DAAaZlrg X-OriginalArrivalTime: 10 Jul 2005 23:47:29.0057 (UTC) FILETIME=[BB6FF110:01C585A9] X-WSS-ID: 6ECF6C1B1KC5353592-01-01 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB01294E26@aunswa002.au.tcnz.net> Date: Mon, 11 Jul 2005 09:47:29 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: Query on RFC1793 (OSPF over demain circuits) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Thanks again, Acee. Cheers, Paresh. -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Sunday, 10 July 2005 09:10 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Query on RFC1793 (OSPF over demain circuits) Paresh Khatri wrote: >Hi all, > =20 > Hi Paresh, >I'm trying to understand the example in Section 2.5 - Interoperability wit= h= unmodified OSPF routers. =20 > >The example states that router B (a non-DC capable router) will treat = DoNotAge LSAs as MaxAge LSAs and will acknowledge them as such to router A.= = But router A will notice that the ack is for a different instance and will= = re-transmit the LSA. My question is - why would router A consider it to be= = an ack for a different instance =3F Is the implication here that router B = would set the Age in the LSAck to be MaxAge and not the Age that was presen= t= in the received LSA =3F > =20 > Yes - note that the example is prefaced with "At the very worst". Acee >Thanks in advance. > >Paresh > > > > >This communication, including any attachments, is confidential. If=20 > you are not the intended recipient, you should not read it - please=20 > contact me immediately, destroy it, and do not copy or use any part of=20 > this communication or disclose anything about it. > > =20 > This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jul 10 19:51:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrlZx-0006wR-EO for ospf-archive@megatron.ietf.org; Sun, 10 Jul 2005 19:51:21 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02893 for ; Sun, 10 Jul 2005 19:51:17 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010A1121@cherry.ease.lsoft.com>; 10 Jul 2005 19:51:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78609138 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 10 Jul 2005 19:51:18 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 10 Jul 2005 19:51:17 -0400 Received: from aksmtpmdr2 (ish3-internal [146.171.1.21]) by smtp3.telecom.co.nz (Postfix) with ESMTP id 4BEF31F1E for ; Mon, 11 Jul 2005 11:45:23 +1200 (NZST) Received: from 146.171.227.25 by aksmtpmdr2 with ESMTP (Tumbleweed MMS SMTP Relay); Mon, 11 Jul 2005 11:46:50 +1200 X-Server-Uuid: 39C90538-1505-4F6D-9FBD-402FA253957C Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp02.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:46:49 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Mon, 11 Jul 2005 09:46:49 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Thread-Topic: Two queries on calculating AS external routes thread-index: AcWEqeGeUC9eGpvOR3qG87pB3HOUuwA/7onA X-OriginalArrivalTime: 10 Jul 2005 23:46:49.0245 (UTC) FILETIME=[A3B51CD0:01C585A9] X-WSS-ID: 6ECF6CE01HG8247741-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB01294E25@aunswa002.au.tcnz.net> Date: Mon, 11 Jul 2005 09:46:49 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Thanks for all your replies, guys. Regards, Paresh. -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Sunday, 10 July 2005 03:16 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Two queries on calculating AS external routes Pat Murphy - (650)329-4044 wrote: >Paresh, > > =20 > >>In my case below, what if the two LSAs are not quite >>functoinally equivalent i.e what if the LSAs have the same >>destination, same cost etc but have different non-zero >>forwarding addresses =3F What happens then =3F Do the same >>tie-breaker rules apply or will it be implementation-dependent =3F >> =20 >> > >The tie breaker rules are not applied. Here the installation=20 >decision process is the same regardless of whether it is=20 >comparing two Type 5 LSAs, or a Type 5 and a Type 7 LSA, or two=20 >Type 7 LSAs. Whether or not both are installed depends on the=20 >pruning done in step (c) as defined in RFC 2328 Section 16.4.1. > =20 > Conceivably, you still could end up with LSAs with differing forwarding=20 addresses of equal cost and equivalent path preference for the prefix. I don't believe this=20 case is covered. However, since the forwarding address costs are equal, I don't think there should=20 be any loops. >Pat > > =20 > This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 12 08:45:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsK8I-0004N6-QN for ospf-archive@megatron.ietf.org; Tue, 12 Jul 2005 08:45:07 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17663 for ; Tue, 12 Jul 2005 08:45:05 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010A2D63@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 8:44:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78824744 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 08:44:45 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 08:44:44 -0400 Received: from aksmtpmdr2 (ish3-internal [146.171.1.21]) by smtp3.telecom.co.nz (Postfix) with ESMTP id B76241F5D for ; Wed, 13 Jul 2005 00:38:47 +1200 (NZST) Received: from 146.171.227.24 by aksmtpmdr2 with ESMTP (Tumbleweed MMS SMTP Relay); Wed, 13 Jul 2005 00:44:34 +1200 X-Server-Uuid: 39C90538-1505-4F6D-9FBD-402FA253957C Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp01.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 00:44:34 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Tue, 12 Jul 2005 22:44:32 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 MIME-Version: 1.0 X-MS-TNEF-Correlator: <44CF9D8D25966C4DB1072958419273DB406828@aunswa002.au.tcnz.net> Thread-Topic: OSPF : Summarization of type-7 lsa's thread-index: AcWDouR0OORs2g+HSjCylRTKRXgRagDPFg9R X-OriginalArrivalTime: 12 Jul 2005 12:44:32.0027 (UTC) FILETIME=[734E56B0:01C586DF] X-WSS-ID: 6ECD64B81HG8587464-01-01 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB406828@aunswa002.au.tcnz.net> Date: Tue, 12 Jul 2005 22:44:31 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: RFC3509 applicability (Alternative Implementations of OSPF Area Border Routers) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi all, Does anyone know if the Cisco implementation still follows ABR behaviour as= = documented in this RFC =3F Thanks, Paresh This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 12 09:23:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsKjr-0002UH-S4 for ospf-archive@megatron.ietf.org; Tue, 12 Jul 2005 09:23:55 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21203 for ; Tue, 12 Jul 2005 09:23:54 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010A2D16@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 9:23:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78828399 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 09:23:53 -0400 Received: from 203.196.196.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 09:23:51 -0400 Received: from netd.com ([10.91.0.11]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id j6CDPrq3031818 for ; Tue, 12 Jul 2005 18:55:55 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <44CF9D8D25966C4DB1072958419273DB406828@aunswa002.au.tcnz.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <42D3C3AE.6020301@netd.com> Date: Tue, 12 Jul 2005 18:50:46 +0530 Reply-To: Mailing List Sender: Mailing List From: tajay Subject: Re: RFC3509 applicability (Alternative Implementations of OSPF Area Border Routers) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <44CF9D8D25966C4DB1072958419273DB406828@aunswa002.au.tcnz.net> Precedence: list Content-Transfer-Encoding: 7bit yeah, cisco follows rfc 3509 implemetation. You can find this by doing simple tests on cisco router.. thanks ajay Paresh Khatri wrote: >Hi all, > >Does anyone know if the Cisco implementation still follows ABR behaviour as documented in this RFC ? > >Thanks, >Paresh > >This communication, including any attachments, is confidential. If > you are not the intended recipient, you should not read it - please > contact me immediately, destroy it, and do not copy or use any part of > this communication or disclose anything about it. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 12 09:46:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsL64-0002py-AW for ospf-archive@megatron.ietf.org; Tue, 12 Jul 2005 09:46:52 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22395 for ; Tue, 12 Jul 2005 09:46:50 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010A2DB2@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 9:46:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78829519 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 09:46:47 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 09:46:07 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 12 Jul 2005 06:46:02 -0700 X-IronPort-AV: i="3.93,283,1115017200"; d="scan'208"; a="648093851:sNHT484943720" 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 j6CDjgvq010368 for ; Tue, 12 Jul 2005 06:45:58 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 09:45:51 -0400 Received: from [10.82.224.72] ([10.82.224.72]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 09:45:50 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <44CF9D8D25966C4DB1072958419273DB406828@aunswa002.au.tcnz.net> <42D3C3AE.6020301@netd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2005 13:45:50.0952 (UTC) FILETIME=[041DBE80:01C586E8] Message-ID: <42D3C98E.4020400@cisco.com> Date: Tue, 12 Jul 2005 09:45:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC3509 applicability (Alternative Implementations of OSPF Area Border Routers) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42D3C3AE.6020301@netd.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Paresh, Ajay, There is one exception, in the implementation the section 2.1 "Active Backbone Connection" definition is relaxed from a full neighbor (RFC3509) to any neighbor in state >= INIT (implementation). Hope this helps, Acee P.S. You can E-mail me privately if you have further questions. tajay wrote: > yeah, > cisco follows rfc 3509 implemetation. You can find this by doing > simple tests on cisco router.. > thanks > ajay > Paresh Khatri wrote: > >> Hi all, >> >> Does anyone know if the Cisco implementation still follows ABR >> behaviour as documented in this RFC ? >> >> Thanks, >> Paresh >> >> This communication, including any attachments, is confidential. If >> you are not the intended recipient, you should not read it - please >> contact me immediately, destroy it, and do not copy or use any part >> of this communication or disclose anything about it. >> >> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 13 10:10:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dshww-0003xK-Mb for ospf-archive@megatron.ietf.org; Wed, 13 Jul 2005 10:10:58 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09887 for ; Wed, 13 Jul 2005 10:10:56 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010A5879@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 10:10:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78971271 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 10:10:38 -0400 Received: from 203.196.196.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 10:10:37 -0400 Received: from netd.com ([10.91.0.11]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id j6DECd4b006444 for ; Wed, 13 Jul 2005 19:42:42 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <44CF9D8D25966C4DB1072958419273DB406828@aunswa002.au.tcnz.net> <42D3C3AE.6020301@netd.com> <42D3C98E.4020400@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <42D5201F.5050801@netd.com> Date: Wed, 13 Jul 2005 19:37:27 +0530 Reply-To: Mailing List Sender: Mailing List From: tajay Subject: type-5 las extarnal-tag field To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42D3C98E.4020400@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit hi guys, I am not clear about extarnal-route-tag field in the type-5 lsa. Can anyone just give me some information about that. Also what should be the default value of the tag field? where it is useful ..? thanks ajay From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 14 21:55:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFQ4-0000dj-0w for ospf-archive@megatron.ietf.org; Thu, 14 Jul 2005 21:55:16 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29031 for ; Thu, 14 Jul 2005 21:55:13 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010A7124@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 21:55:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79144641 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 21:54:58 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 21:54:58 -0400 Received: from aksmtpmdr2 (ish3-internal [146.171.1.21]) by smtp3.telecom.co.nz (Postfix) with ESMTP id 20E7520AF for ; Fri, 15 Jul 2005 13:49:01 +1200 (NZST) Received: from 146.171.227.25 by aksmtpmdr2 with ESMTP (Tumbleweed MMS SMTP Relay); Fri, 15 Jul 2005 13:54:44 +1200 X-Server-Uuid: 39C90538-1505-4F6D-9FBD-402FA253957C Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp02.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Jul 2005 13:54:33 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Fri, 15 Jul 2005 11:54:33 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Thread-Topic: type-5 las extarnal-tag field thread-index: AcWHtLkojMyy2HQ3RxCjcYid5tps1gBKbhkg X-OriginalArrivalTime: 15 Jul 2005 01:54:33.0274 (UTC) FILETIME=[257A21A0:01C588E0] X-WSS-ID: 6EC9C8AC1HG9160040-20-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB40682C@aunswa002.au.tcnz.net> Date: Fri, 15 Jul 2005 11:54:33 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: type-5 las extarnal-tag field To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable HI Ajay, The external route tag is not used by OSPF itself. It is transparently = conveyed with type-5/type-7 LSAs so that applications can make any desired = use of it. One particular application is when you are doing two-way = redistribution at multiple points. In such a case, you could associate a = certain tag when redistributing routes into OSPF. That way, when you are = redistributing *from* OSPF into another protocol at some other = redistribution point, you can dis-regard the routes that have that tag = associated with it. HTH, Paresh. -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of tajay Sent: Thursday, 14 July 2005 12:07 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: type-5 las extarnal-tag field hi guys, I am not clear about extarnal-route-tag field in the type-5 lsa. Can=20 anyone just give me some information about that. Also what should be=20 the default value of the tag field=3F where it is useful ..=3F=20 thanks ajay This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 14 22:32:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFzi-0005CI-0B for ospf-archive@megatron.ietf.org; Thu, 14 Jul 2005 22:32:06 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00947 for ; Thu, 14 Jul 2005 22:32:02 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010A71F0@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 22:32:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79146757 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 22:32:00 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 22:32:00 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j6F2W0976673 for ; Thu, 14 Jul 2005 19:32:00 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j6F2VsQ35185 for ; Thu, 14 Jul 2005 19:31:54 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v733) References: <44CF9D8D25966C4DB1072958419273DB40682C@aunswa002.au.tcnz.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.733) Message-ID: <228ACFCD-0B8E-425A-A977-8DC9C7F6D0D0@juniper.net> Date: Thu, 14 Jul 2005 20:31:53 -0600 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: type-5 las extarnal-tag field To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <44CF9D8D25966C4DB1072958419273DB40682C@aunswa002.au.tcnz.net> Precedence: list Content-Transfer-Encoding: 7bit Back in prehistory (end of the Reagan years), this was known as the "Milo Word" (since Milo Medin was the guy who wanted it put in there.) It was originally intended to be a pre-BGP way of controlling external route distribution, by carrying an AS number (for example.) The choice of which externals to distribute back out of the domain was made in part by tags added at the point where the routes came in. Yes, in those days people did inject full Internet routing into their IGP, but it was a smaller, slower world back then. Now it's sort of a Rorschach test for routing interactions. On Jul 14, 2005, at 7:54 PM, Paresh Khatri wrote: > HI Ajay, > > The external route tag is not used by OSPF itself. It is > transparently conveyed with type-5/type-7 LSAs so that applications > can make any desired use of it. One particular application is when > you are doing two-way redistribution at multiple points. In such a > case, you could associate a certain tag when redistributing routes > into OSPF. That way, when you are redistributing *from* OSPF into > another protocol at some other redistribution point, you can dis- > regard the routes that have that tag associated with it. > > HTH, > Paresh. > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > tajay > Sent: Thursday, 14 July 2005 12:07 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: type-5 las extarnal-tag field > > > hi guys, > I am not clear about extarnal-route-tag field in the type-5 lsa. Can > anyone just give me some information about that. Also what should be > the default value of the tag field? where it is useful ..? > > thanks > ajay > > > This communication, including any attachments, is confidential. If > you are not the intended recipient, you should not read it - please > contact me immediately, destroy it, and do not copy or use any > part of > this communication or disclose anything about it. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 14 23:52:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtHFl-0005nO-Te for ospf-archive@megatron.ietf.org; Thu, 14 Jul 2005 23:52:45 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05037 for ; Thu, 14 Jul 2005 23:52:43 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010A75CA@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 23:52:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79151399 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 23:52:41 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 23:52:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: type-5 las extarnal-tag field Thread-Index: AcWI5WNuBtbzLdSwRo+wDIPbcCM7HQACqBUA Message-ID: Date: Thu, 14 Jul 2005 20:53:10 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: type-5 las extarnal-tag field To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, Nice summary given by Dave. Here is something I think it can be used for: - http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave Katz Sent: Friday, July 15, 2005 8:02 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: type-5 las extarnal-tag field Back in prehistory (end of the Reagan years), this was known as the =20 "Milo Word" (since Milo Medin was the guy who wanted it put in =20 there.) It was originally intended to be a pre-BGP way of =20 controlling external route distribution, by carrying an AS number =20 (for example.) The choice of which externals to distribute back out =20 of the domain was made in part by tags added at the point where the =20 routes came in. Yes, in those days people did inject full Internet =20 routing into their IGP, but it was a smaller, slower world back then. Now it's sort of a Rorschach test for routing interactions. On Jul 14, 2005, at 7:54 PM, Paresh Khatri wrote: > HI Ajay, > > The external route tag is not used by OSPF itself. It is =20 > transparently conveyed with type-5/type-7 LSAs so that applications =20 > can make any desired use of it. One particular application is when =20 > you are doing two-way redistribution at multiple points. In such a =20 > case, you could associate a certain tag when redistributing routes =20 > into OSPF. That way, when you are redistributing *from* OSPF into =20 > another protocol at some other redistribution point, you can dis-=20 > regard the routes that have that tag associated with it. > > HTH, > Paresh. > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of =20 > tajay > Sent: Thursday, 14 July 2005 12:07 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: type-5 las extarnal-tag field > > > hi guys, > I am not clear about extarnal-route-tag field in the type-5 lsa. Can > anyone just give me some information about that. Also what should be > the default value of the tag field? where it is useful ..? > > thanks > ajay > > > This communication, including any attachments, is confidential. If > you are not the intended recipient, you should not read it - please > contact me immediately, destroy it, and do not copy or use any =20 > part of > this communication or disclose anything about it. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 15 01:32:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIoW-0005mN-0P for ospf-archive@megatron.ietf.org; Fri, 15 Jul 2005 01:32:44 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11054 for ; Fri, 15 Jul 2005 01:32:42 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010A753F@cherry.ease.lsoft.com>; Fri, 15 Jul 2005 1:32:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79157888 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Jul 2005 01:32:38 -0400 Received: from 203.196.196.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 15 Jul 2005 01:32:37 -0400 Received: from netd.com ([10.91.0.11]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id j6F5Ya4b013462 for ; Fri, 15 Jul 2005 11:04:39 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <44CF9D8D25966C4DB1072958419273DB40682C@aunswa002.au.tcnz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <42D749A9.1010406@netd.com> Date: Fri, 15 Jul 2005 10:59:13 +0530 Reply-To: Mailing List Sender: Mailing List From: tajay Subject: Re: type-5 las extarnal-tag field To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <44CF9D8D25966C4DB1072958419273DB40682C@aunswa002.au.tcnz.net> Precedence: list Content-Transfer-Encoding: 7bit hi pareash, thanks for explaination, i have some doubts, Paresh Khatri wrote: >HI Ajay, > >The external route tag is not used by OSPF itself. It is transparently conveyed with type-5/type-7 LSAs so that applications can make any desired use of it. One particular application is when you are doing two-way redistribution at multiple points. In such a case, you could associate a certain tag when redistributing routes into OSPF. That way, when you are redistributing *from* OSPF into another protocol at some other redistribution point, you can dis-regard the routes that have that tag associated with it. > Do you mean controlling redistribution based on tag field..??? I am just giving one example... R1------------------------R2---------------------------R3--------------------------R4 R1 and R2 runs RIP. R2 and R3 runs OSPF. R3 and R4 runs BGP. Now suppose at R2 I am redistributing routes into ospf domain with tag field 100 . Also suppose there are some static routes at R2 which i am redistributing into OSPF domain with tag 200. Now my question is how R3 can use these tag field while redistributing into BGP domain. In normal impementation do we have that type of configuration command which allows filtering based on tag fields. thanks ajay > >HTH, >Paresh. > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of tajay >Sent: Thursday, 14 July 2005 12:07 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: type-5 las extarnal-tag field > > >hi guys, >I am not clear about extarnal-route-tag field in the type-5 lsa. Can >anyone just give me some information about that. Also what should be >the default value of the tag field? where it is useful ..? > >thanks >ajay > > >This communication, including any attachments, is confidential. If > you are not the intended recipient, you should not read it - please > contact me immediately, destroy it, and do not copy or use any part of > this communication or disclose anything about it. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 15 01:37:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIsm-0006xZ-RG for ospf-archive@megatron.ietf.org; Fri, 15 Jul 2005 01:37:09 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11315 for ; Fri, 15 Jul 2005 01:37:03 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010A7594@cherry.ease.lsoft.com>; Fri, 15 Jul 2005 1:37:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79158066 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Jul 2005 01:36:51 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 15 Jul 2005 01:36:51 -0400 Received: from aksmtpmdr1 (ish2-internal [146.171.1.20]) by smtp3.telecom.co.nz (Postfix) with ESMTP id D3DC51EEB for ; Fri, 15 Jul 2005 17:30:53 +1200 (NZST) Received: from 146.171.227.25 by aksmtpmdr1 with ESMTP (Tumbleweed MMS SMTP Relay); Fri, 15 Jul 2005 17:36:41 +1200 X-Server-Uuid: 50880B64-500D-4147-A4F0-826C22747D83 Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp02.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Jul 2005 17:36:40 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Fri, 15 Jul 2005 15:36:36 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Thread-Topic: type-5 las extarnal-tag field thread-index: AcWI/q1H6fxAa/3yS1qkQAauUJhz1wAADivw X-OriginalArrivalTime: 15 Jul 2005 05:36:36.0409 (UTC) FILETIME=[2AAF3290:01C588FF] X-WSS-ID: 6EC994E31KC6310928-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB01294E4F@aunswa002.au.tcnz.net> Date: Fri, 15 Jul 2005 15:36:36 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: type-5 las extarnal-tag field To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Ajay, You sure can. It does not really matter where/how the tag was set - you ca= n= match on it when redistributing into BGP (depending, of course, on the = platform/software you are using) HTH, Paresh. -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of tajay Sent: Friday, 15 July 2005 03:29 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: type-5 las extarnal-tag field hi pareash, thanks for explaination, i have some doubts, Paresh Khatri wrote: >HI Ajay, > >The external route tag is not used by OSPF itself. It is transparently = conveyed with type-5/type-7 LSAs so that applications can make any desired = use of it. One particular application is when you are doing two-way = redistribution at multiple points. In such a case, you could associate a = certain tag when redistributing routes into OSPF. That way, when you are = redistributing *from* OSPF into another protocol at some other = redistribution point, you can dis-regard the routes that have that tag = associated with it. > Do you mean controlling redistribution based on tag field..=3F=3F=3F I am just giving one example... R1------------------------R2---------------------------R3------------------= --------R4 R1 and R2 runs RIP. =20 R2 and R3 runs OSPF. R3 and R4 runs BGP. Now suppose at R2 I am redistributing routes into ospf domain with tag=20 =66ield 100 . Also suppose there are some static routes at R2 which i am=20 redistributing into OSPF domain with tag 200. Now my question is how R3 can use these tag field while redistributing=20 into BGP domain. In normal impementation do we have that type of=20 configuration command which allows filtering based on tag fields. thanks ajay =20 > >HTH, >Paresh. > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of tajay >Sent: Thursday, 14 July 2005 12:07 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: type-5 las extarnal-tag field > > >hi guys, >I am not clear about extarnal-route-tag field in the type-5 lsa. Can=20 >anyone just give me some information about that. Also what should be=20 >the default value of the tag field=3F where it is useful ..=3F=20 > >thanks >ajay > > >This communication, including any attachments, is confidential. If=20 > you are not the intended recipient, you should not read it - please=20 > contact me immediately, destroy it, and do not copy or use any part of=20 > this communication or disclose anything about it. > > =20 > This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 15 07:31:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtOPY-0001cB-92 for ospf-archive@megatron.ietf.org; Fri, 15 Jul 2005 07:31:20 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26397 for ; Fri, 15 Jul 2005 07:31:18 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010A79F6@cherry.ease.lsoft.com>; Fri, 15 Jul 2005 7:31:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79214462 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Jul 2005 07:31:15 -0400 Received: from 80.168.70.142 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 15 Jul 2005 07:31:15 -0400 Received: from du-069-0111.access.clara.net ([217.158.132.111] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DtOPS-000CKs-7Z; Fri, 15 Jul 2005 12:31:15 +0100 References: <42D6FAB3.9050804@kddilabs.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <080e01c58931$0d210dc0$d6849ed9@Puppy> Date: Fri, 15 Jul 2005 12:29:51 +0100 Reply-To: Mailing List Sender: Mailing List From: Adrian Farrel Subject: Re: GMPLS OSPF-TE MIB Comments: To: mpls@ietf.org Comments: cc: Tomohiro Otani To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Cross-posting to the OSPF and MPLS mailing lists. Folk in CCAMP are starting to look at what MIB extensions are needed to handle TE and GMPLS extensions to OSPF. This work is at a very early stage. We anticipate that this work will require significant review in the OSPF, MPLS and CCAMP working groups. For the moment it would be helpful to concentrate discussions on one mailing list. Let's make that CCAMP for now. Thanks, Adrian ----- Original Message ----- From: "Tomohiro Otani" To: Sent: Friday, July 15, 2005 12:52 AM Subject: GMPLS OSPF-TE MIB > Hi everyone, > > We posted a new draft about GMPLS OSPF-TE MIB as follows. > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-ospf-mib-00.txt > > We welcome your comments and feedbacks, pls. > And please make a comment whether this is within ccamp WG or not (OSPF-WG?). > > We believe that this is a very significant definition of OSPF-TE MIB, > being complementary to other GMPLS related MIBs (TE/LSR/LMP mibs) in order > to deploy GMPLS control plane in the actual environment with simple but > reliable network management. > > With best regards, > > tomo > > ------------------------------------ > Tomohiro Otani > KDDI R&D Laboratories, Inc. > Optical network architecture lab. > 2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan > TEL: +81-49-278-7357 > FAX: +81-49-278-7811 > E-mail: otani@kddilabs.jp > ------------------------------------ > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jul 16 07:07:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtkWL-0004iA-51 for ospf-archive@megatron.ietf.org; Sat, 16 Jul 2005 07:07:49 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08517 for ; Sat, 16 Jul 2005 07:07:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010A88FD@cherry.ease.lsoft.com>; Sat, 16 Jul 2005 7:07:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79320237 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 16 Jul 2005 07:07:46 -0400 Received: from 64.233.162.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 16 Jul 2005 06:57:44 -0400 Received: by zproxy.gmail.com with SMTP id i11so482624nzh for ; Sat, 16 Jul 2005 03:57:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=lXIR/BF+J3gSlOWRKh+N3GZ+ym7PtLhivDFguYI8N9GTkpo20G9fHeTAgvvFT/psZ6Pk0VBvYCtnoKKDv6F5o9Aqj9p0UP141cpXFg8EcpdzJS2bYraZ0BnFUEv7MhkFtl7Lu4lVLKtyxsTzCGNSl7gpezTUfyUsHixpS77wVdI= Received: by 10.36.222.18 with SMTP id u18mr2333195nzg; Sat, 16 Jul 2005 03:57:44 -0700 (PDT) Received: by 10.36.5.1 with HTTP; Sat, 16 Jul 2005 03:57:44 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: <6e100ff005071603577d36f1d@mail.gmail.com> Date: Sat, 16 Jul 2005 18:57:44 +0800 Reply-To: Mailing List Sender: Mailing List From: Biju Mammen Subject: Shortcut ABR To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi all: From what I understand, the draft corresponding to Shortcut ABR has been expired.Any reason as to why it never went into an RFC stage? Any known vendors supporting this option?? regards Biju Mammen From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jul 16 15:04:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtrxl-00019N-5c for ospf-archive@megatron.ietf.org; Sat, 16 Jul 2005 15:04:37 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24999 for ; Sat, 16 Jul 2005 15:04:35 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010A8BB1@cherry.ease.lsoft.com>; Sat, 16 Jul 2005 15:04:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79344471 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 16 Jul 2005 15:04:32 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 16 Jul 2005 15:04:32 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dtrxf-000Jzv-Jd; Sat, 16 Jul 2005 19:04:31 +0000 X-Priority: 3 (Normal) References: <6e100ff005071603577d36f1d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <255781769.20050716120414@psg.com> Date: Sat, 16 Jul 2005 12:04:14 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Shortcut ABR Comments: To: Biju Mammen To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6e100ff005071603577d36f1d@mail.gmail.com> Precedence: list Content-Transfer-Encoding: 7bit Biju, The shortcut ABR was an example of a mechanism where addressing the corner cases made as complex as dealing with the problem it was attempting to solve, so I decided to drop it. As for the implementations, I coded some version of it in Zebra long time ago, and I don't think it was ever implemented on a commercial router. -- Alex http://www.psg.com/~zinin Saturday, July 16, 2005, 3:57:44 AM, Biju Mammen wrote: > Hi all: > From what I understand, the draft corresponding to Shortcut > ABR has been expired.Any reason as to why it never went into an RFC > stage? > Any known vendors supporting this option?? > regards > Biju Mammen From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 18 01:26:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuO9V-00051Z-AB for ospf-archive@megatron.ietf.org; Mon, 18 Jul 2005 01:26:53 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19568 for ; Mon, 18 Jul 2005 01:26:52 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010AA5C8@cherry.ease.lsoft.com>; Mon, 18 Jul 2005 1:26:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79460366 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Jul 2005 01:26:29 -0400 Received: from 203.196.196.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 18 Jul 2005 01:26:28 -0400 Received: from netd.com ([10.91.0.11]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id j6I5Sf4b031878 for ; Mon, 18 Jul 2005 10:58:44 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6e100ff005071603577d36f1d@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <42DB3CD0.7020202@netd.com> Date: Mon, 18 Jul 2005 10:53:28 +0530 Reply-To: Mailing List Sender: Mailing List From: tajay Subject: static neighbors To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6e100ff005071603577d36f1d@mail.gmail.com> Precedence: list Content-Transfer-Encoding: 7bit hi all, I have aquestions related to neighbor FSM in rfc2328. Do you believe that neighbor FSM given in rfc2328 is applicable for the statically configured neighbors also? with regards, ajay From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 18 16:30:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DucGR-0004B4-EQ for ospf-archive@megatron.ietf.org; Mon, 18 Jul 2005 16:30:59 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24296 for ; Mon, 18 Jul 2005 16:30:56 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010AAF47@cherry.ease.lsoft.com>; Mon, 18 Jul 2005 16:30:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79575810 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Jul 2005 16:30:31 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 18 Jul 2005 16:30:31 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 18 Jul 2005 13:30:31 -0700 X-IronPort-AV: i="3.93,297,1115017200"; d="scan'208"; a="199023751:sNHT26330532" 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 j6IKUBVj019800 for ; Mon, 18 Jul 2005 13:30:28 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 16:30:18 -0400 Received: from [64.102.198.175] ([64.102.198.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 16:30:18 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6e100ff005071603577d36f1d@mail.gmail.com> <42DB3CD0.7020202@netd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 20:30:18.0311 (UTC) FILETIME=[83115D70:01C58BD7] Message-ID: <42DC115A.2070706@cisco.com> Date: Mon, 18 Jul 2005 16:30:18 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: static neighbors To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42DB3CD0.7020202@netd.com> Precedence: list Content-Transfer-Encoding: 7bit tajay wrote: > hi all, > I have aquestions related to neighbor FSM in rfc2328. > Do you believe that neighbor FSM given in rfc2328 is applicable for > the statically configured neighbors also? Hi Ajay, Yes. Note that the initial application for statically configured neighbors was in support of NBMA networks. Thanks, Acee > with regards, > ajay > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 25 04:45:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwyag-0002UG-Jw for ospf-archive@megatron.ietf.org; Mon, 25 Jul 2005 04:45:38 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28366 for ; Mon, 25 Jul 2005 04:45:36 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010B30C5@cherry.ease.lsoft.com>; Mon, 25 Jul 2005 4:45:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80294999 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Jul 2005 04:45:07 -0400 Received: from 129.188.136.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 25 Jul 2005 04:35:07 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6P8iVVW010111 for ; Mon, 25 Jul 2005 01:44:35 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j6P8fKUX019290 for ; Mon, 25 Jul 2005 03:41:21 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Jul 2005 14:04:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C590F3.BE37567C" Message-ID: <772BCEF88A1DD91191F80011856715F3047CB229@zin24exm01.ap.mot.com> Date: Mon, 25 Jul 2005 14:04:59 +0530 Reply-To: Mailing List Sender: Mailing List From: Khan Amir-G20247 Subject: Query..Pls help To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C590F3.BE37567C Content-Type: text/plain Hi I'm having a query regarding OSPF MIB updates "draft-ietf-ospf-mib-update-08.txt". In the current draft a new OSPF Host Table object "ospfHostCfgAreaID" has been added this object is of read-create type and is a updation to "ospfHostAreaID" which is now read-only. I don't understand why was there a need to introduce a new object "ospfHostCfgAreaID" when "ospfHostAreaID" already exist ? "ospfHostAreaID" was initially read-create only, it could have made to serve the purpose as ospfHostCfgAreaID serves now, if it woud have been enhanced to support the feature to configure the new area if one doesn't exists. Besides this, we have to update the "ospfHostAreaID" object everytime with "ospfHostCfgAreaID" object whenever its been configured by the user, which is a good as updating "ospfHostAreaID" directly. Pls revert back with your comments at the earliest. Regards Aamir Khan Motorola India ------_=_NextPart_001_01C590F3.BE37567C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTguMiI+DQo8VElUTEU+UXVlcnkuLlBs cyBoZWxwPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBD T0xPUj0iIzAwMDBGRiIgU0laRT0yIEZBQ0U9IlZlcmRhbmEiPkhpPC9GT05UPg0KPC9QPg0KPEJS Pg0KDQo8UD48Rk9OVCBDT0xPUj0iIzAwMDBGRiIgU0laRT0yIEZBQ0U9IlZlcmRhbmEiPkknbSBo YXZpbmcgYSBxdWVyeSByZWdhcmRpbmcgT1NQRiBNSUIgdXBkYXRlcyAmcXVvdDtkcmFmdC1pZXRm LW9zcGYtbWliLXVwZGF0ZS0wOC50eHQmcXVvdDsuIEluIHRoZSBjdXJyZW50IGRyYWZ0IGEgbmV3 IE9TUEYgSG9zdCBUYWJsZSBvYmplY3QgJnF1b3Q7b3NwZkhvc3RDZmdBcmVhSUQmcXVvdDsgaGFz IGJlZW4gYWRkZWQgdGhpcyBvYmplY3QgaXMgb2YgcmVhZC1jcmVhdGUgdHlwZSBhbmQgaXMgYSB1 cGRhdGlvbiB0byAmcXVvdDtvc3BmSG9zdEFyZWFJRCZxdW90OyB3aGljaCBpcyBub3cgcmVhZC1v bmx5LiA8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBDT0xPUj0iIzAwMDBGRiIgU0laRT0yIEZBQ0U9 IlZlcmRhbmEiPkkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgd2FzIHRoZXJlIGEgbmVlZCB0byBpbnRy b2R1Y2UgYSBuZXcgb2JqZWN0ICZxdW90O29zcGZIb3N0Q2ZnQXJlYUlEJnF1b3Q7IHdoZW4gJnF1 b3Q7b3NwZkhvc3RBcmVhSUQmcXVvdDsgYWxyZWFkeSBleGlzdCA/IDwvRk9OVD48L1A+DQoNCjxQ PjxGT05UIENPTE9SPSIjMDAwMEZGIiBTSVpFPTIgRkFDRT0iVmVyZGFuYSI+JnF1b3Q7b3NwZkhv c3RBcmVhSUQmcXVvdDsgd2FzIGluaXRpYWxseSByZWFkLWNyZWF0ZSBvbmx5LCBpdCBjb3VsZCBo YXZlIG1hZGUgdG8gc2VydmUgdGhlIHB1cnBvc2UgYXMgb3NwZkhvc3RDZmdBcmVhSUQgc2VydmVz IG5vdywgaWYgaXQgd291ZCBoYXZlIGJlZW4gZW5oYW5jZWQgdG8gc3VwcG9ydCB0aGUgZmVhdHVy ZSB0byBjb25maWd1cmUgdGhlIG5ldyBhcmVhIGlmJm5ic3A7IG9uZSBkb2Vzbid0IGV4aXN0cy4g PC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBGQUNFPSJWZXJk YW5hIj5CZXNpZGVzIHRoaXMsIHdlIGhhdmUgdG8gdXBkYXRlIHRoZSAmcXVvdDtvc3BmSG9zdEFy ZWFJRCZxdW90OyBvYmplY3QgZXZlcnl0aW1lIHdpdGggJnF1b3Q7b3NwZkhvc3RDZmdBcmVhSUQm cXVvdDsgb2JqZWN0IHdoZW5ldmVyIGl0cyBiZWVuIGNvbmZpZ3VyZWQgYnkgdGhlIHVzZXIsIHdo aWNoIGlzIGEgZ29vZCBhcyB1cGRhdGluZyAmcXVvdDtvc3BmSG9zdEFyZWFJRCZxdW90OyBkaXJl Y3RseS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBDT0xPUj0iIzAwMDBGRiIgU0laRT0yIEZBQ0U9 IlZlcmRhbmEiPlBscyByZXZlcnQgYmFjayB3aXRoIHlvdXIgY29tbWVudHMgYXQgdGhlIGVhcmxp ZXN0LjwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCg0KPFA+PEI+PEk+PEZPTlQgQ09MT1I9IiM4 MDgwRkYiIFNJWkU9MiBGQUNFPSJUcmVidWNoZXQgTVMiPlJlZ2FyZHM8L0ZPTlQ+PC9JPjwvQj4N CjxCUj48Qj48ST48Rk9OVCBDT0xPUj0iIzgwODBGRiIgU0laRT0yIEZBQ0U9IlRyZWJ1Y2hldCBN UyI+QWFtaXIgS2hhbjwvRk9OVD48L0k+PC9CPjxJPjwvST4NCjxCUj48Qj48ST48Rk9OVCBDT0xP Uj0iIzgwODBGRiIgU0laRT0yIEZBQ0U9IlRyZWJ1Y2hldCBNUyI+TW90b3JvbGEgSW5kaWE8L0ZP TlQ+PC9JPjwvQj48ST48L0k+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01C590F3.BE37567C-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 25 11:01:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4Sj-00006y-NX for ospf-archive@megatron.ietf.org; Mon, 25 Jul 2005 11:01:49 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27833 for ; Mon, 25 Jul 2005 11:01:47 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010B342D@cherry.ease.lsoft.com>; Mon, 25 Jul 2005 11:01:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80369483 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Jul 2005 11:01:44 -0400 Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 25 Jul 2005 10:51:44 -0400 Received: from zbl6c004.us.nortel.com (zbl6c004.corpeast.baynetworks.com [132.245.205.54]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j6PEpgK25870 for ; Mon, 25 Jul 2005 10:51:42 -0400 (EDT) Received: by zbl6c004.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <3ZDVL35Z>; Mon, 25 Jul 2005 10:51:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59128.5DEDBFCE" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0FF6B4F2@zbl6c004.corpeast.baynetworks.com> Date: Mon, 25 Jul 2005 10:51:41 -0400 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: Query..Pls help To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59128.5DEDBFCE Content-Type: text/plain Backward compatibility rules forbid changing the max-access of an existing object when updating a MIB. -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Khan Amir-G20247 Sent: Monday, July 25, 2005 4:35 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Query..Pls help Hi I'm having a query regarding OSPF MIB updates "draft-ietf-ospf-mib-update-08.txt". In the current draft a new OSPF Host Table object "ospfHostCfgAreaID" has been added this object is of read-create type and is a updation to "ospfHostAreaID" which is now read-only. I don't understand why was there a need to introduce a new object "ospfHostCfgAreaID" when "ospfHostAreaID" already exist ? "ospfHostAreaID" was initially read-create only, it could have made to serve the purpose as ospfHostCfgAreaID serves now, if it woud have been enhanced to support the feature to configure the new area if one doesn't exists. Besides this, we have to update the "ospfHostAreaID" object everytime with "ospfHostCfgAreaID" object whenever its been configured by the user, which is a good as updating "ospfHostAreaID" directly. Pls revert back with your comments at the earliest. Regards Aamir Khan Motorola India ------_=_NextPart_001_01C59128.5DEDBFCE Content-Type: text/html Message
Backward compatibility rules forbid changing the max-access of an existing object
when updating a MIB.
-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Khan Amir-G20247
Sent: Monday, July 25, 2005 4:35 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Query..Pls help



Hi


I'm having a query regarding OSPF MIB updates "draft-ietf-ospf-mib-update-08.txt". In the current draft a new OSPF Host Table object "ospfHostCfgAreaID" has been added this object is of read-create type and is a updation to "ospfHostAreaID" which is now read-only.

I don't understand why was there a need to introduce a new object "ospfHostCfgAreaID" when "ospfHostAreaID" already exist ?

"ospfHostAreaID" was initially read-create only, it could have made to serve the purpose as ospfHostCfgAreaID serves now, if it woud have been enhanced to support the feature to configure the new area if  one doesn't exists.

Besides this, we have to update the "ospfHostAreaID" object everytime with "ospfHostCfgAreaID" object whenever its been configured by the user, which is a good as updating "ospfHostAreaID" directly.

Pls revert back with your comments at the earliest.



Regards
Aamir Khan
Motorola India

------_=_NextPart_001_01C59128.5DEDBFCE--