From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 2 10:31:34 2003 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 KAA22013 for ; Thu, 2 Oct 2003 10:31:34 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00BF2E73@cherry.ease.lsoft.com>; Thu, 2 Oct 2003 10:31:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56704956 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 2 Oct 2003 10:31:38 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 2 Oct 2003 10:31:38 -0400 Received: from redback.com (pptp-6-160.redback.com [155.53.6.160]) by prattle.redback.com (Postfix) with ESMTP id DF1F915480C for ; Thu, 2 Oct 2003 07:31:36 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F7C36BD.2010305@redback.com> Date: Thu, 2 Oct 2003 10:31:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: RFC 3630 - Traffic Engineering (TE) Extensions to OSPF Version 2 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The OSPF TE Draft has been published. Thanks to Dave, Derek, and Kireeti for their persistence in taking this draft though all the revisions and reviews. http://www.ietf.org/rfc/rfc3630.txt?number=3630 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 3 15:19:06 2003 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 PAA22463 for ; Fri, 3 Oct 2003 15:19:05 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00BF63E3@cherry.ease.lsoft.com>; Fri, 3 Oct 2003 15:19:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56734931 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 3 Oct 2003 15:19:09 -0400 Received: from 208.229.251.198 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 3 Oct 2003 15:09:09 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by oxide.local (8.12.9/8.12.6) with ESMTP id h93J96DF019183 for ; Fri, 3 Oct 2003 12:09:07 -0700 (PDT) X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <2147483647.1065182946@[208.229.251.198]> Date: Fri, 3 Oct 2003 12:09:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Ed Kern Subject: Last Call for draft-ietf-tewg-diff-te-proto-05.txt and friends To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ##Note: This last call is being sent to te-wg,ISIS,OSPF,MPLS in separate emails to trim silly "respond-all" people and aggressive junk filters. This will serve as a last call for the standards track document draft-ietf-tewg-diff-te-proto-05.txt available at and the "friends" (accompanying bandwidth control drafts) going towards experimental: draft-ietf-tewg-diff-te-russian-04.txt draft-ietf-tewg-diff-te-mar-02.txt draft-ietf-tewg-diff-te-mam-01.txt This last call will be three weeks ending 10/24/03 after which time many beers will be consumed. All comments about the drafts should be to/on the te-wg@ops.ietf.org list. All flames about duplicates of this message to me. thx Ed From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 3 16:45:18 2003 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 QAA27526 for ; Fri, 3 Oct 2003 16:45:17 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00BF6821@cherry.ease.lsoft.com>; Fri, 3 Oct 2003 16:45:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56740753 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 3 Oct 2003 16:45:13 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 3 Oct 2003 16:35:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26226; Fri, 3 Oct 2003 16:34:55 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200310032034.QAA26226@ietf.org> Date: Fri, 3 Oct 2003 16:34:54 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-2547-dnbit-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs Author(s) : E. Rosen, et. al. Filename : draft-ietf-ospf-2547-dnbit-01.txt Pages : 6 Date : 2003-10-3 [VPN] describes a method by which a Service Provider (SP) may provide an 'IP VPN' service to its customers. In VPNs of that sort, a Customer Edge (CE) Router and a Provider Edge Router become routing peers, and the customer routes are sent to the SP. BGP is then used to carry the customer routes across the SP's backbone to other PE routers, and the routes are then sent to other CE routers. Since CE routers and PE routers are routing peers, it is customary to run a routing protocol between them. [VPN] allows a number of different PE-CE protocols. If OSPF is used as the PE-CE routing protocol, the PE must execute additional procedures not specified in [VPN]; these procedures are specified in [OSPF-VPN]. These additional procedures translate customer OSPF routes from a CE router into BGP routes. The BGP routes are sent to the other PE routers, which translate them back into OSPF routes, and then distribute them to CE routers. During this translation, some of the information needed to prevent loops may be lost. The procedures specified in this document remedy this situation by specifying that one of the OSPF options bits be used to ensure that when a VPN route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-2547-dnbit-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-2547-dnbit-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-2547-dnbit-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-3164352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-2547-dnbit-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-2547-dnbit-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-3164352.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 8 15:22:20 2003 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 PAA05014 for ; Wed, 8 Oct 2003 15:22:20 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C02AA8@cherry.ease.lsoft.com>; Wed, 8 Oct 2003 15:22:23 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57270671 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Oct 2003 15:22:22 -0400 Received: from 132.151.6.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 8 Oct 2003 15:12:16 -0400 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1A7Jiu-0003p1-Ib; Wed, 08 Oct 2003 15:11:48 -0400 X-test-idtracker: no Message-ID: Date: Wed, 8 Oct 2003 15:11:48 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Last Call: 'Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance' to BCP To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list The IESG has received a request from the Open Shortest Path First IGP WG to consider the following document: - 'Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 13 02:50:33 2003 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 CAA24972 for ; Mon, 13 Oct 2003 02:50:32 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C0A1C7@cherry.ease.lsoft.com>; Mon, 13 Oct 2003 2:50:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57688905 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Oct 2003 02:50:34 -0400 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 13 Oct 2003 02:40:33 -0400 Received: from kailash1.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Mon, 13 Oct 2003 12:15:07 +0530 Received: from rameshrr (rameshrr.future.futsoft.com [10.8.7.24]) by kailash1.future.futsoft.com (8.11.0/8.11.0) with SMTP id h9D6eCT07532 for ; Mon, 13 Oct 2003 12:10:13 +0530 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Message-ID: <014f01c39154$dbe1e200$1807080a@future.futsoft.com> Date: Mon, 13 Oct 2003 12:10:13 +0530 Reply-To: Mailing List Sender: Mailing List From: Rayapureddi Ramesh Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable
 


***************************************************************************=
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************=
From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 13 17:32:39 2003 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 RAA00391 for ; Mon, 13 Oct 2003 17:32:39 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C0B1CD@cherry.ease.lsoft.com>; Mon, 13 Oct 2003 17:32:46 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57779521 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Oct 2003 17:32:44 -0400 Received: from 32.97.110.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 13 Oct 2003 17:32:44 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9DLWhE6103616 for ; Mon, 13 Oct 2003 17:32:43 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9DLWd66087310 for ; Mon, 13 Oct 2003 15:32:41 -0600 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/13/2003 15:32:41 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Mon, 13 Oct 2003 17:32:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Seeming contradiction on forwarding addresses? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list RFC 2328 says, in section 12.4.4.1 regarding forwarding addresses in external LSAs: > Note that when the forwarding address field is non- > zero, it should point to a router belonging to > another Autonomous System. But then when discussing calculation of external routes in section 16.4 it says: > If the forwarding address is non-zero, look up the > forwarding address in the routing table.[24] The matching > routing table entry must specify an intra-area or inter-area > path; if no such path exists, do nothing with the LSA and > consider the next in the list. So the RFC says that a forwarding address should be to an AS external address, but no one can use an external LSA if the only way to reach the forwarding address is via an AS External route? Footnote 24 re-emphasizes that point also. Is there something I am missing here? Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 13 17:53:10 2003 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 RAA01113 for ; Mon, 13 Oct 2003 17:53:10 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C0B3BB@cherry.ease.lsoft.com>; Mon, 13 Oct 2003 17:53:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57780669 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Oct 2003 17:53:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 13 Oct 2003 17:53:17 -0400 Received: from redback.com (pptp-6-156.redback.com [155.53.6.156]) by prattle.redback.com (Postfix) with ESMTP id 7B39D52A760 for ; Mon, 13 Oct 2003 14:53:15 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F8B1ECA.2080000@redback.com> Date: Mon, 13 Oct 2003 17:53:14 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Seeming contradiction on forwarding addresses? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Mike, Mike Fox wrote: >RFC 2328 says, in section 12.4.4.1 regarding forwarding addresses in >external LSAs: > > > >>Note that when the forwarding address field is non- >>zero, it should point to a router belonging to >>another Autonomous System. >> >> > >But then when discussing calculation of external routes in section 16.4 it >says: > > > >>If the forwarding address is non-zero, look up the >>forwarding address in the routing table.[24] The matching >>routing table entry must specify an intra-area or inter-area >>path; if no such path exists, do nothing with the LSA and >>consider the next in the list. >> >> > >So the RFC says that a forwarding address should be to an AS external >address, but no one can use an external LSA if the only way to reach the >forwarding address is via an AS External route? Footnote 24 re-emphasizes >that point also. Is there something I am missing here? > The thing here is that the forwarding address is for a router that provides a path to IPv4 prefixes outside the OSPF routing domain. However, the forwarding address itself must be reachable by an OSPF intra-area or inter-area route (which is by definition part of the OSPF routing domain). In this context, I prefer to use the term OSPF routing domain rather than AS since there will often be non-OSPF routes in use within an AS running OSPF as the IGP. I hope I've made sense. Acee > >Mike >----------------------------------------------------------------------- >Enterprise Network Solutions >----------------------------------------------------------------------- >Research Triangle Park, NC USA > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 14 01:30:49 2003 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 BAA13906 for ; Tue, 14 Oct 2003 01:30:49 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C0BE7D@cherry.ease.lsoft.com>; Tue, 14 Oct 2003 1:30:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57824132 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Oct 2003 01:30:53 -0400 Received: from 66.28.8.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Oct 2003 01:30:52 -0400 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-2.tower-20.messagelabs.com!1066109299!2972060 X-StarScan-Version: 5.1.9.3; banners=bankofny.com,-,- Received: (qmail 2882 invoked from network); 14 Oct 2003 05:28:50 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-2.tower-20.messagelabs.com with SMTP; 14 Oct 2003 05:28:50 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Tue, 14 Oct 2003 01:30:48 -0400 Reply-To: Mailing List Sender: Mailing List From: rmalhotra@BANKOFNY.COM Subject: Ravi Malhotra is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting 10/10/2003 and will not return until 10/20/2003. I will respond to your message when I return. Thank You, Ravi Malhotra ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Tue Oct 14 14:23:14 2003 Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22769 for ; Tue, 14 Oct 2003 14:23:14 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <3.003910D4@grape.ease.lsoft.com>; Tue, 14 Oct 2003 14:23:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57889964 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Oct 2003 14:23:20 -0400 Received: from 32.97.110.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Oct 2003 14:23:20 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9EINJE6301236 for ; Tue, 14 Oct 2003 14:23:19 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9EINIlA115270 for ; Tue, 14 Oct 2003 12:23:18 -0600 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/14/2003 12:23:18 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Tue, 14 Oct 2003 14:23:04 -0400 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: Seeming contradiction on forwarding addresses? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee wrote: > the forwarding address itself > must be reachable > by an OSPF intra-area or inter-area route (which is by definition part > of the OSPF routing > domain). In this context, I prefer to use the term OSPF routing domain > rather than AS since > there will often be non-OSPF routes in use within an AS running OSPF as > the IGP. This still does not resolve the contradiction. RFC 2328 contains the following text in section 2.3: ====begin quoted text===== For example, suppose in Figure 2 there is an additional router attached to Network N6, called Router RTX. Suppose further that RTX does not participate in OSPF routing, but does exchange BGP information with the AS boundary router RT7. Then, Router RT7 would end up advertising OSPF external routes for all destinations that should be routed to RTX. An extra hop will sometimes be introduced if packets for these destinations need always be routed first to Router RT7 (the advertising router). To deal with this situation, the OSPF protocol allows an AS boundary router to specify a "forwarding address" in its AS- external-LSAs. In the above example, Router RT7 would specify RTX's IP address as the "forwarding address" for all those destinations whose packets should be routed directly to RTX. ====end quoted text==== Since RTX is not participating in OSPF routing, a route to it would not be internal to the OSPF AS (or routing domain if you prefer). Yet this text says to use RTX's address as the forwarding address. Because of the other requirement that the forwarding address be reachable via an OSPF internal path, no other router would be able to use this AS External advertisement. This becomes more of a problem in IPv6 but it also causes problems in IPv4. Consider this example, modified from the RFC: | +---+ | |RTA|-----| +---+ +---+ |-----|RTX| | +---+ +---+ | |RTB|-----| +---+ | | +---+ | |RTC|-----| +---+ | | + RTA-RTC are running OSPF. RTX is not. RTA advertises an AS external default route with a forwarding address of RTX. In IPv4, that forwarding address would be in the network's subnet so even though RTX is not running OSPF, RTB and RTC learn OSPF subnet routes that would allow packets to be forwarded to RTX. However if the system programmer coded a static route to RTX on RTB or RTC, that route would be more specific than the OSPF subnet route, so it would be found when looking up RTX, and since it's not internal to the OSPF domain the default route becomes unusable by RTB and RTC. In IPv6 the situation gets worse because there is no requirement for all addresses on the link to fall into the same prefix. RTX could have a global address that is not in any prefix known by the other routers, requiring a static route to be coded -- but if the route to RTX is static (i.e., not OSPF), that makes it unusable as a forwarding address for any AS external LSAs. Why not simply require that the forwarding address be reachable, period? The route could be static, RIP, BGP or whatever. As long as it's possible to route to the forwarding address, why be picky about the type of route? Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 14 15:37:49 2003 Received: from LIME.ease.lsoft.com (lime.ease.lsoft.com [209.119.0.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26531 for ; Tue, 14 Oct 2003 15:37:48 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.1.37) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0001FE37@LIME.ease.lsoft.com>; Tue, 14 Oct 2003 15:33:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57896085 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Oct 2003 15:37:41 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Oct 2003 15:37:39 -0400 Received: from redback.com (pptp-6-156.redback.com [155.53.6.156]) by prattle.redback.com (Postfix) with ESMTP id F1F486F03CE for ; Tue, 14 Oct 2003 12:37:37 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F8C507E.5060008@redback.com> Date: Tue, 14 Oct 2003 15:37:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Seeming contradiction on forwarding addresses? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Mike - See inline below: Mike Fox wrote: >Acee wrote: > > > >>the forwarding address itself >>must be reachable >>by an OSPF intra-area or inter-area route (which is by definition part >>of the OSPF routing >>domain). In this context, I prefer to use the term OSPF routing domain >>rather than AS since >>there will often be non-OSPF routes in use within an AS running OSPF as >>the IGP. >> >> > >This still does not resolve the contradiction. RFC 2328 contains the >following text in section 2.3: > > >====begin quoted text===== >For example, >suppose in Figure 2 there is an additional router attached to >Network N6, called Router RTX. Suppose further that RTX does >not participate in OSPF routing, but does exchange BGP >information with the AS boundary router RT7. Then, Router RT7 >would end up advertising OSPF external routes for all >destinations that should be routed to RTX. An extra hop will >sometimes be introduced if packets for these destinations need >always be routed first to Router RT7 (the advertising router). > >To deal with this situation, the OSPF protocol allows an AS >boundary router to specify a "forwarding address" in its AS- >external-LSAs. In the above example, Router RT7 would specify >RTX's IP address as the "forwarding address" for all those >destinations whose packets should be routed directly to RTX. >====end quoted text==== > >Since RTX is not participating in OSPF routing, a route to it would not be >internal to the OSPF AS (or routing domain if you prefer). Yet this text >says to use RTX's address as the forwarding address. > RTX can have be connected to a mult-access network running OSPF even if it doesn't run OSPF itself. For example, let's say the subnet address is 192.168.2.0/24 and RTX's address on N6 is 192.168.2.55. There will still be an OSPF route to 192.168.2.0/24 in the route tables for all the OSPF routers. > Because of the >other requirement that the forwarding address be reachable via an OSPF >internal path, no other router would be able to use this AS External >advertisement. > >This becomes more of a problem in IPv6 but it also causes problems in IPv4. >Consider this example, modified from the RFC: > > > | > +---+ | > |RTA|-----| +---+ > +---+ |-----|RTX| > | +---+ > +---+ | > |RTB|-----| > +---+ | > | > +---+ | > |RTC|-----| > +---+ | > | > + > >RTA-RTC are running OSPF. RTX is not. RTA advertises an AS external >default route with a forwarding address of RTX. In IPv4, that forwarding >address would be in the network's subnet so even though RTX is not running >OSPF, RTB and RTC learn OSPF subnet routes that would allow packets to be >forwarded to RTX. However if the system programmer coded a static route to >RTX on RTB or RTC, that route would be more specific than the OSPF subnet >route, so it would be found when looking up RTX, and since it's not >internal to the OSPF domain the default route becomes unusable by RTB and >RTC. > The OSPF specification only considers OSPF routes when doing the lookup. Implementations that do not maintain a separate OSPF route table or multiple routes (in order of preference) will have to use a modified route lookup. > >In IPv6 the situation gets worse because there is no requirement for all >addresses on the link to fall into the same prefix. RTX could have a >global address that is not in any prefix known by the other routers, >requiring a static route to be coded -- but if the route to RTX is static >(i.e., not OSPF), that makes it unusable as a forwarding address for any AS >external LSAs. > Nope - even if the prefix is configured on all the OSPFv3 routers it still should be installed in every OSPFv3 since it will be advertised in the intra-area prefix LSA which refers to the network LSA (the DR originates both of these). The biggest issue that I see with forwarding addresses in OSPFv3 is that if other IPv6 protocols install link local next-hops (like OSPFv3 does), they'll rarely be advertised. > >Why not simply require that the forwarding address be reachable, period? >The route could be static, RIP, BGP or whatever. As long as it's possible >to route to the forwarding address, why be picky about the type of route? > Because if it isn't an OSPF path we can't be sure that other routers in the OSPF routing domain have reachability to the forwarding address and it is better to use the route to the ASBR. > >Mike >----------------------------------------------------------------------- >Enterprise Network Solutions >----------------------------------------------------------------------- >Research Triangle Park, NC USA > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 14 17:49:29 2003 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 RAA04352 for ; Tue, 14 Oct 2003 17:49:28 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C0D5E4@cherry.ease.lsoft.com>; Tue, 14 Oct 2003 17:49:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57909319 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Oct 2003 17:48:09 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Oct 2003 17:48:09 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id A9A643A72A2 for ; Tue, 14 Oct 2003 14:48:07 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030820091000.9203.qmail@webmail10.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F8C6E75.1020009@redback.com> Date: Tue, 14 Oct 2003 17:45:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: RFC 2328 Section 16.5 - Incremental SPF Calculation Question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030820091000.9203.qmail@webmail10.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Arun, I lost track of this due to the lack of a subject - hence, a belated response. A summary path from the transit area may update a route to a destination which is reachable via the backbone. If this cost is larger than it was previously and the updated route is an intra-area route, the backbone dijkstra calculation must be run to assure this is still the best path. Make sense? Note that there are a multitude of incremental optimizations which may provide the same results as 16.5. Thanks, Acee arunsy wrote: > Hi all, > Would someone be able to explain the following clause in RFC 2328 > section 16.5 (Incremental Updates -- Summary LSAs) Case 2 (Area A > is a transit area and the router is an ABR). > > Case 2: Area A is a transit area and the router is an area > border router. > In this case, the following calculations must be > performed. > First, if N's routing table entry presently contains one > or > more inter-area paths that utilize the transit area Area > A, > these paths should be removed. If this removes all paths > from the routing table entry, the entry should be > invalidated. The entry's old values should be saved for > later comparisons. Next the calculation in Section 16.3 > must > be run again for the single destination N. If the results > of > this calculation have caused the cost to N to increase, > the > complete routing table calculation must be rerun starting > with the Dijkstra algorithm specified in Section 16.1. > Otherwise, if the cost/path to an AS boundary router (as > would be the case for a Type 4 summary-LSA) or to any > forwarding addresses has changed, all AS-external-LSAs > will > have to be reexamined by rerunning the calculation > in > Section 16.4. Otherwise, if N is now newly unreachable, > the > calculation in Section 16.4 must be rerun for the single > destination N, in case an alternate external route to N > exists. > > Why complete routing table calculation need to be rerun if the > calculated new route has the higher cost than that of older one. > And how this behaviour is different from case 1? > > And one more thing, how a router (ABR) knows whether the path of > the route is utilizing the transit area, since all the inter-area > routes in ABR are always associated with the Back Bone (even after > step 16.3). > > Thanks and Regards, > ARun SY. > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 15 18:06:00 2003 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 SAA26157 for ; Wed, 15 Oct 2003 18:06:00 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C14A52@cherry.ease.lsoft.com>; Wed, 15 Oct 2003 18:06:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58058566 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 15 Oct 2003 18:06:04 -0400 Received: from 208.236.67.13 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Oct 2003 18:06:04 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9FM613H010906 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 15 Oct 2003 18:06:02 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h9FM5tXX001817 for ; Wed, 15 Oct 2003 18:05:55 -0400 (EDT) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 10/15/2003 06:03:57 PM, Serialize complete at 10/15/2003 06:03:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0079630B85256DC0_=" Message-ID: Date: Wed, 15 Oct 2003 18:05:52 -0400 Reply-To: Mailing List Sender: Mailing List From: ashgoel@HSS.HNS.COM Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart message in MIME format. --=_alternative 0079630B85256DC0_= Content-Type: text/plain; charset="us-ascii" --=_alternative 0079630B85256DC0_= Content-Type: text/html; charset="us-ascii" --=_alternative 0079630B85256DC0_=-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 17 08:46:20 2003 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 IAA00009 for ; Fri, 17 Oct 2003 08:46:20 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C176C2@cherry.ease.lsoft.com>; Fri, 17 Oct 2003 8:46:26 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57743081 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Oct 2003 08:46:24 -0400 Received: from 205.158.62.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Oct 2003 08:46:24 -0400 Received: from 205-158-62-68.outblaze.com (205-158-62-68.outblaze.com [205.158.62.68]) by spf13.us4.outblaze.com (Postfix) with QMQP id 813881800418 for ; Fri, 17 Oct 2003 12:46:19 +0000 (GMT) Received: (qmail 74815 invoked from network); 17 Oct 2003 12:46:19 -0000 Received: from unknown (HELO ws5-2.us4.outblaze.com) (205.158.62.132) by 205-158-62-153.outblaze.com with SMTP; 17 Oct 2003 12:46:19 -0000 Received: (qmail 11174 invoked by uid 1001); 17 Oct 2003 12:46:19 -0000 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [203.197.138.194] by ws5-2.us4.outblaze.com with http for niveda@indiainfo.com; Fri, 17 Oct 2003 18:16:19 +0530 X-Originating-Ip: 203.197.138.194 X-Originating-Server: ws5-2.us4.outblaze.com Message-ID: <20031017124619.11173.qmail@indiainfo.com> Date: Fri, 17 Oct 2003 18:16:19 +0530 Reply-To: Mailing List Sender: Mailing List From: Niveda Monyvannan Subject: Neighbor priority To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, There is an option to configure the priority for the NBMA neighbor in RFC 1850. When the hello packet is received from the neighbor, it will be updated in the neighbor data structure and will be used for Election. What is the use of configuring this? We have seen a mail thread stating that in CISCO also, After configuring this neighbor priority, the value is shown in the 'show neighbor' is reflecting the priority specified in the hello of the neighbor. Why is this redundant configuration Regards, Niveda -- ______________________________________________ IndiaInfo Mail - the free e-mail service with a difference! www.indiainfo.com Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes! Powered by Outblaze From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 17 09:54:54 2003 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 JAA02117 for ; Fri, 17 Oct 2003 09:54:54 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C17976@cherry.ease.lsoft.com>; Fri, 17 Oct 2003 9:55:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57746996 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Oct 2003 09:55:00 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Oct 2003 09:55:00 -0400 Received: from redback.com (pptp-6-138.redback.com [155.53.6.138]) by prattle.redback.com (Postfix) with ESMTP id 63DC7712C41 for ; Fri, 17 Oct 2003 06:54:58 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20031017124619.11173.qmail@indiainfo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F8FF4AB.6050406@redback.com> Date: Fri, 17 Oct 2003 09:54:51 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Neighbor priority To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031017124619.11173.qmail@indiainfo.com> Precedence: list Content-Transfer-Encoding: 7bit Niveda Monyvannan wrote: >Hi, > There is an option to configure the priority for the NBMA neighbor in RFC 1850. >When the hello packet is received from the neighbor, it will be updated in the neighbor data structure and will be used for Election. > What is the use of configuring this? > Hi Niveda, You don't need to know the exact priority for a neighbor in advance but on NBMA networks you do need know whether or not the router is DR eligible to whether when to send hellos to the neighbor (all DR eligible neighbors on an NBMA network need to exchange hellos every hello interval seconds). Rather than add a separate MIB variable for DR eligibility, ospfNbrPriority is made read-create. For more information on sending hello packets on NBMA networks, refer to section 9.5.1 in RFC2328. Thanks, Acee > > We have seen a mail thread stating that in CISCO also, > >After configuring this neighbor priority, the value is shown in the 'show neighbor' is reflecting the priority specified in the hello of the neighbor. > >Why is this redundant configuration > >Regards, >Niveda >-- >______________________________________________ >IndiaInfo Mail - the free e-mail service with a difference! www.indiainfo.com >Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes! > >Powered by Outblaze > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 17 15:45:45 2003 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 PAA19415 for ; Fri, 17 Oct 2003 15:45:45 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C1802F@cherry.ease.lsoft.com>; Fri, 17 Oct 2003 15:45:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57770578 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Oct 2003 15:45:50 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Oct 2003 15:35:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18459; Fri, 17 Oct 2003 15:35:37 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200310171935.PAA18459@ietf.org> Date: Fri, 17 Oct 2003 15:35:36 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-graceful-impl-report-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Graceful OSPF Restart Implementation Report Author(s) : A. Lindem Filename : draft-ietf-ospf-graceful-impl-report-00.txt Pages : 6 Date : 2003-10-17 Graceful OSPF Restart provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-graceful-impl-report-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-graceful-impl-report-00.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-graceful-impl-report-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-17124120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-graceful-impl-report-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-graceful-impl-report-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-17124120.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 22 19:09:59 2003 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 TAA04944 for ; Wed, 22 Oct 2003 19:09:58 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C209B1@cherry.ease.lsoft.com>; Wed, 22 Oct 2003 19:10:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58320703 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Oct 2003 19:10:04 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Oct 2003 19:00:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03704; Wed, 22 Oct 2003 18:59:50 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200310222259.SAA03704@ietf.org> Date: Wed, 22 Oct 2003 18:59:50 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF Tunnel capability TLVs Author(s) : S. Eng, et. al. Filename : draft-eng-nalawade-ospf-tunnel-cap-00.txt Pages : 8 Date : 2003-10-22 As increasing number of tunnels are deployed in a Provider core, there is a need for improving the efficiency and ease of tunnel establishment. OSPF running as the IGP in a Provider core, can act as the signalling agent for the Tunnel endpoints. OSPF can carry tunnel endpoint information in the intra-AS scope, easing BGP of the extra burden of signalling within the core. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eng-nalawade-ospf-tunnel-cap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-eng-nalawade-ospf-tunnel-cap-00.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-eng-nalawade-ospf-tunnel-cap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-22183218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-eng-nalawade-ospf-tunnel-cap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-eng-nalawade-ospf-tunnel-cap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183218.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 24 11:01:40 2003 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 LAA06679 for ; Fri, 24 Oct 2003 11:01:39 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C237EF@cherry.ease.lsoft.com>; Fri, 24 Oct 2003 11:01:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58524346 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Oct 2003 11:01:45 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 24 Oct 2003 10:51:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05350; Fri, 24 Oct 2003 10:51:28 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200310241451.KAA05350@ietf.org> Date: Fri, 24 Oct 2003 10:51:27 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-cap-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Extensions to OSPF for Advertising Optional Router Capabilities Author(s) : A. Lindem, N. Shen, R. Aggarwal, S. Shaffer, J. Vasseur Filename : draft-ietf-ospf-cap-01.txt Pages : 8 Date : 2003-10-23 It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information (RI) opaque LSA is proposed for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-cap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24103739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-cap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-cap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103739.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 24 12:46:55 2003 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 MAA16742 for ; Fri, 24 Oct 2003 12:46:55 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C23BA2@cherry.ease.lsoft.com>; Fri, 24 Oct 2003 12:47:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58535269 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Oct 2003 12:47:02 -0400 Received: from 65.205.166.188 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 24 Oct 2003 12:47:01 -0400 Received: from dc1laptop (unknown [172.16.24.103]) by jera.movaz.com (Postfix) with SMTP id A261B16012; Fri, 24 Oct 2003 12:47:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: Date: Fri, 24 Oct 2003 12:47:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Dan Dovolsky Subject: Re: I-D ACTION:draft-ietf-ospf-cap-01.txt Comments: To: acee@redback.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200310241451.KAA05350@ietf.org> Precedence: list Content-Transfer-Encoding: 7bit I have couple questions to authors of this draft. 1. Could you, please, enumerate reasons why you want to have Router Options advertisements in the new separated Opaque LSA? Why the TE Router Opaque LSA is not good for it? RFC3630 doesn't prevent adding of new tlvs into it. 2. Is it possible scenario when you don't have TE Router Opaque LSA but you do have the new RI Opaque LSA? Thanks, Dan Dovolsky -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Internet-Drafts@IETF.ORG Sent: Friday, October 24, 2003 10:51 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: I-D ACTION:draft-ietf-ospf-cap-01.txt 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, N. Shen, R. Aggarwal, S. Shaffer, J. Vasseur Filename : draft-ietf-ospf-cap-01.txt Pages : 8 Date : 2003-10-23 It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information (RI) opaque LSA is proposed for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-cap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 24 14:11:50 2003 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 OAA20804 for ; Fri, 24 Oct 2003 14:11:50 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C23D86@cherry.ease.lsoft.com>; Fri, 24 Oct 2003 14:11:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58541373 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Oct 2003 14:11:56 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 24 Oct 2003 14:11:56 -0400 Received: from redback.com (unknown [155.53.6.4]) by prattle.redback.com (Postfix) with ESMTP id 0B8EE48100F; Fri, 24 Oct 2003 11:11:55 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F996B61.8040606@redback.com> Date: Fri, 24 Oct 2003 14:11:45 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-cap-01.txt Comments: To: ddovolsky@movaz.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Dan Dovolsky wrote: >I have couple questions to authors of this draft. > >1. Could you, please, enumerate reasons why you want to have Router Options >advertisements in the new separated Opaque LSA? >Why the TE Router Opaque LSA is not good for it? RFC3630 doesn't prevent >adding of new tlvs into it. > This is a more generalized mechanism. I'm sure what it is used for will be a topic for debate. > >2. Is it possible scenario when you don't have TE Router Opaque LSA but you >do have the new RI Opaque LSA? > Yes. > >Thanks, >Dan Dovolsky > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of >Internet-Drafts@IETF.ORG >Sent: Friday, October 24, 2003 10:51 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: I-D ACTION:draft-ietf-ospf-cap-01.txt > > >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, N. Shen, R. Aggarwal, S. Shaffer, J. >Vasseur > Filename : draft-ietf-ospf-cap-01.txt > Pages : 8 > Date : 2003-10-23 > >It is useful for routers in an OSPF routing domain to know the capabilities >of their neighbors and other routers in the OSPF routing domain. This draft >proposes extensions to OSPF for advertising optional router capabilities. A >new Router Information (RI) opaque LSA is proposed for this purpose. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ospf-cap-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 24 14:12:34 2003 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 OAA20826 for ; Fri, 24 Oct 2003 14:12:33 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C23BE7@cherry.ease.lsoft.com>; Fri, 24 Oct 2003 14:12:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58539954 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Oct 2003 14:12:40 -0400 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 24 Oct 2003 14:02:40 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9OI2cjP012188 for ; Fri, 24 Oct 2003 11:02:39 -0700 (PDT) Received: from cisco.com (sjc-vpn4-249.cisco.com [10.21.80.249]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANM69598; Fri, 24 Oct 2003 11:02:37 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F99693D.1060600@cisco.com> Date: Fri, 24 Oct 2003 11:02:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: I-D ACTION:draft-ietf-ospf-cap-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dan, Dan Dovolsky wrote: > I have couple questions to authors of this draft. > > 1. Could you, please, enumerate reasons why you want to have Router Options > advertisements in the new separated Opaque LSA? > Why the TE Router Opaque LSA is not good for it? RFC3630 doesn't prevent > adding of new tlvs into it. RFC3630 TE LSAs are only of area flooding scope. RI LSA can provision a domain-wide scope. Also this draft is not describing TE-specific purpose, but tunnels generally. It is a better idea to use a generic mechanism to advertise router capabilites, especially when there may be other applications that will use this LSA. > > 2. Is it possible scenario when you don't have TE Router Opaque LSA but you > do have the new RI Opaque LSA? If a router is simply advertising a particular tunnel capability, a TE Opaque LSA may not be requried in such a case. Thanks, Sandy > > Thanks, > Dan Dovolsky > > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Internet-Drafts@IETF.ORG > Sent: Friday, October 24, 2003 10:51 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: I-D ACTION:draft-ietf-ospf-cap-01.txt > > > 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, N. Shen, R. Aggarwal, S. Shaffer, J. > Vasseur > Filename : draft-ietf-ospf-cap-01.txt > Pages : 8 > Date : 2003-10-23 > > It is useful for routers in an OSPF routing domain to know the capabilities > of their neighbors and other routers in the OSPF routing domain. This draft > proposes extensions to OSPF for advertising optional router capabilities. A > new Router Information (RI) opaque LSA is proposed for this purpose. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ospf-cap-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 27 03:46:56 2003 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 DAA01479 for ; Mon, 27 Oct 2003 03:46:55 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C271FB@cherry.ease.lsoft.com>; Mon, 27 Oct 2003 3:47:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58766214 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Oct 2003 03:47:01 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Oct 2003 03:47:00 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9R8kxI23127 for ; Mon, 27 Oct 2003 10:46:59 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 27 Oct 2003 10:47:01 +0200 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 02:46:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Examining Transit Area's Summary-LSAs Thread-Index: AcOcZuCqlVDFnkJ3QWaMvEzynR1zFQ== X-OriginalArrivalTime: 27 Oct 2003 08:46:58.0951 (UTC) FILETIME=[E20B8970:01C39C66] Message-ID: <8D260779A766FB4A9C1739A476F84FA401546E65@daebe009.americas.nokia.com> Date: Mon, 27 Oct 2003 02:46:58 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Examining Transit Area's Summary-LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I have some doubt about bullet 5 of section 16.3 in 2328. It says=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D If this cost is less than the cost occurring in N's routing table entry, overwrite N's list of next hops with those used for BR, and set N's routing table cost to IAC. Else, if IAC is the same as N's current cost, add BR's list of next hops to N's list of next hops. In any case, the area associated with N's routing table entry must remain the backbone area, and the path type (either intra-area or inter-area) must also remain the same. =3D=3D=3D=3D=3D=3D=3D=3D=3D and Section 16.1.1 says: =3D=3D=3D=3D=3D=3D=3D If the destination is a router connected to the calculating=20 router via a virtual link, the setting of the next hop=20 should be deferred until the calculation in Section 16.3. =3D=3D=3D=3D=3D=3D=3D Let say a router that is one end of the virtual link, learns about a prefix N with cost 4 while calculating=20 inter-area routes. It installs a route with no nexthop because the nexthop destination is connected via a virtual link. Now when it starts examining the transit area summary LSAs, it finds an LSA describing prefix N with cost 3 and the virtual link end point is 2 hops away. So the iac=20 becomes 5. Now as iac is more than the previously calculated cost 4, no nexthop is installed according to algorithm described above. The route remains without the nexthop and=20 thus unusable. Am I missing something .. I have a setup where the above scenario becomes a reality and a route becomes unusable :( I have fixed the problem by extending the algorithm described above. =3D=3D=3D=3D=3D If iac is more than the cost occurring in N's routing table entry AND there is no nexthop associated with N's routing table entry, then add BR's list of next hops to N's list of next hops and set N's routing table cost=20 to IAC. =3D=3D=3D=3D=3D Comments/Questions ?? Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 27 07:13:42 2003 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 HAA08814 for ; Mon, 27 Oct 2003 07:13:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C274FC@cherry.ease.lsoft.com>; Mon, 27 Oct 2003 7:13:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58797041 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Oct 2003 07:13:33 -0500 Received: from 213.31.213.194 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Oct 2003 07:03:32 -0400 Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Oct 2003 14:03:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1255" Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B35301A900ED@mxtlv1.corrigent.com> Date: Mon, 27 Oct 2003 14:02:59 +0200 Reply-To: Mailing List Sender: Mailing List From: Alex Levit Subject: Opaque LSA question: attaching OSPF interface to different area To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi All, Does anyone know about any specification what is to be done to Opaque LSA type 9 (or 10) when an OSPF interface through which it was originated is attached to area different than it was at the originating time? The LSA probably needs to be altered and re-originated, but does it making any sense that OSPF will do the job itself or the opaque application needs to be involved here? Does it matter if interface was brought down and then up after reattaching to new area? Thanks, Alex From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 27 09:51:00 2003 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 JAA16924 for ; Mon, 27 Oct 2003 09:50:59 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C2792B@cherry.ease.lsoft.com>; Mon, 27 Oct 2003 9:51:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58821376 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Oct 2003 09:51:05 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Oct 2003 09:51:05 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AEC518620A1 for ; Mon, 27 Oct 2003 06:51:04 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24440-05 for ; Mon, 27 Oct 2003 06:51:04 -0800 (PST) Received: from redback.com (pptp-6-131.redback.com [155.53.6.131]) by prattle.redback.com (Postfix) with ESMTP id 08B708620A0 for ; Mon, 27 Oct 2003 06:51:04 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA401546E65@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F9D30CE.5070008@redback.com> Date: Mon, 27 Oct 2003 09:50:54 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Examining Transit Area's Summary-LSAs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401546E65@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Mukesh, Mukesh.Gupta@NOKIA.COM wrote: >I have some doubt about bullet 5 of section 16.3 in 2328. >It says >========= >If this cost is less than the cost occurring in N's routing >table entry, overwrite N's list of next hops with those used >for BR, and set N's routing table cost to IAC. Else, if IAC >is the same as N's current cost, add BR's list of next hops >to N's list of next hops. In any case, the area associated >with N's routing table entry must remain the backbone area, >and the path type (either intra-area or inter-area) must >also remain the same. >========= > >and Section 16.1.1 says: >======= >If the destination is a router connected to the calculating >router via a virtual link, the setting of the next hop >should be deferred until the calculation in Section 16.3. >======= > >Let say a router that is one end of the virtual link, >learns about a prefix N with cost 4 while calculating >inter-area routes. > I believe your scenario could also apply to intra-area backbone prefixes. >It installs a route with no nexthop >because the nexthop destination is connected via a virtual >link. Now when it starts examining the transit area summary >LSAs, it finds an LSA describing prefix N with cost 3 and >the virtual link end point is 2 hops away. So the iac >becomes 5. Now as iac is more than the previously calculated >cost 4, no nexthop is installed according to algorithm >described above. The route remains without the nexthop and >thus unusable. > >Am I missing something .. > I guess the assumption is that ABR that is the virtual link endpoint will always advertise a summary into the transit area which has same cost as the backbone path. > >I have a setup where the above scenario becomes a reality >and a route becomes unusable :( I have fixed the problem >by extending the algorithm described above. > >===== >If iac is more than the cost occurring in N's routing >table entry AND there is no nexthop associated with N's >routing table entry, then add BR's list of next hops >to N's list of next hops and set N's routing table cost >to IAC. > I must admit that I don't defer the next hop calculation until processing transit area summaries. Rather, I update the next hops if there is a lower cost path via transit area. >===== > >Comments/Questions ?? > >Regards >Mukesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 27 10:02:39 2003 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 KAA17577 for ; Mon, 27 Oct 2003 10:02:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C279F0@cherry.ease.lsoft.com>; Mon, 27 Oct 2003 10:02:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58821949 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Oct 2003 10:02:46 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Oct 2003 10:02:46 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8500E6C0D86 for ; Mon, 27 Oct 2003 07:02:45 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25764-08 for ; Mon, 27 Oct 2003 07:02:45 -0800 (PST) Received: from redback.com (pptp-6-131.redback.com [155.53.6.131]) by prattle.redback.com (Postfix) with ESMTP id CC3D16C0D85 for ; Mon, 27 Oct 2003 07:02:44 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8FA6CEF9A4E42B48A5F8DC038655B35301A900ED@mxtlv1.corrigent.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F9D338A.7010003@redback.com> Date: Mon, 27 Oct 2003 10:02:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Opaque LSA question: attaching OSPF interface to different area To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8FA6CEF9A4E42B48A5F8DC038655B35301A900ED@mxtlv1.corrigent.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Alex, Alex Levit wrote: >Hi All, > >Does anyone know about any specification what is to be done to Opaque LSA >type 9 (or 10) >when an OSPF interface through which it was originated is attached to area >different than it was >at the originating time? > For type 9, it is obvious the initial LSA should be purged and a new one originated. For type 10, the LSA is associated with an area as opposed to an interface. If the contents of the LSA are specific to the interface that has been moved to a different area (e.g., a TE LSA containing a link TLV), then the LSA should be purged from its former area and originated in the new area. > >The LSA probably needs to be altered and re-originated, but does it making >any sense that OSPF will do the job itself >or the opaque application needs to be involved here? > Whether it needs to get involved or not, the LSA purge/originations should be signaled to the opaque application. > >Does it matter if interface was brought down and then up after reattaching >to new area? > I'd say "no" - from the perspective of OSPF it is a different interface. > >Thanks, >Alex > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 27 11:20:06 2003 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 LAA23131 for ; Mon, 27 Oct 2003 11:20:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C27A0F@cherry.ease.lsoft.com>; Mon, 27 Oct 2003 11:20:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58826960 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Oct 2003 11:20:13 -0500 Received: from 64.4.27.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Oct 2003 11:10:12 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Oct 2003 08:10:12 -0800 Received: from 66.21.69.204 by by8fd.bay8.hotmail.msn.com with HTTP; Mon, 27 Oct 2003 16:10:12 GMT X-Originating-IP: [66.21.69.204] X-Originating-Email: [asn08@hotmail.com] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Oct 2003 16:10:12.0258 (UTC) FILETIME=[CCE42820:01C39CA4] Message-ID: Date: Mon, 27 Oct 2003 16:10:12 +0000 Reply-To: Mailing List Sender: Mailing List From: abc xyz Subject: OSPF Virtual link question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi All, I had a question regarding OSPF Virtual links, consider the following network diagram: 192.168.1.1_______area0______192.168.1.10 ____|____ ____|____ | RUT | | TR1 | |_______| |_________| | | 172.20.5.1_____area1_____172.20.5.1 A virtual link is configured across area 1 between the RUT & TR1. When I run my code I end up adding the route to TR1 via area 0 since it's the same cost as across area 1. As a result of this my virtual link never comes up because it does not know how to get to TR1 from area 1. Could you please point me to the section in RFC 2328 that deals with this case? Thanks for your time. Regards, Archana _________________________________________________________________ Send instant messages to anyone on your contact list with MSN Messenger 6.0. Try it now FREE! http://msnmessenger-download.com From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 27 11:59:56 2003 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 LAA25076 for ; Mon, 27 Oct 2003 11:59:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C27C4D@cherry.ease.lsoft.com>; Mon, 27 Oct 2003 12:00:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58830697 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Oct 2003 12:00:04 -0500 Received: from 209.119.1.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Oct 2003 12:00:04 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.FE669192@wnt.dc.lsoft.com>; Mon, 27 Oct 2003 12:00:04 -0500 Message-ID: Date: Mon, 27 Oct 2003 12:00:04 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: OSPF Virtual link question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Archana, In my humble opinion, there are two logically different routes from RUT to TR1: first one to TR1 as ABR, and the second one to TR1 as ASBR. When you talk about the former, a route to ABR in one area cannot affect another area's route to the same ABR. In your case RUT preferred the backbone to reach the ASBR TR1, but this doesn't mean anything in regard to ABR TR1. Virtual link should work. Thanks, Igor On Mon, 27 Oct 2003 16:10:12 +0000, abc xyz wrote: >Hi All, > >I had a question regarding OSPF Virtual links, consider the following >network diagram: > > 192.168.1.1_______area0______192.168.1.10 > ____|____ ____|____ > | RUT | | TR1 | > |_______| |_________| > | | > 172.20.5.1_____area1_____172.20.5.1 > > >A virtual link is configured across area 1 between the RUT & TR1. When I >run my code I end up adding the route to TR1 via area 0 since it's the same >cost as across area 1. As a result of this my virtual link never comes up >because it does not know how to get to TR1 from area 1. Could you please >point me to the section in RFC 2328 that deals with this case? > >Thanks for your time. > >Regards, >Archana > >_________________________________________________________________ >Send instant messages to anyone on your contact list with MSN Messenger >6.0. Try it now FREE! http://msnmessenger-download.com From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 27 12:21:47 2003 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 MAA26245 for ; Mon, 27 Oct 2003 12:21:47 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C27B85@cherry.ease.lsoft.com>; Mon, 27 Oct 2003 12:21:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58837021 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Oct 2003 12:21:55 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Oct 2003 12:21:54 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4391029BA6B for ; Mon, 27 Oct 2003 09:21:54 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14401-04 for ; Mon, 27 Oct 2003 09:21:54 -0800 (PST) Received: from redback.com (pptp-6-131.redback.com [155.53.6.131]) by prattle.redback.com (Postfix) with ESMTP id A473629BA69 for ; Mon, 27 Oct 2003 09:21:53 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F9D5427.1060805@redback.com> Date: Mon, 27 Oct 2003 12:21:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF Virtual link question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Archana, abc xyz wrote: > Hi All, > > I had a question regarding OSPF Virtual links, consider the following > network diagram: > > 192.168.1.1_______area0______192.168.1.10 > ____|____ ____|____ > | RUT | | TR1 | > |_______| |_________| > | | > 172.20.5.1_____area1_____172.20.5.1 > > > A virtual link is configured across area 1 between the RUT & TR1. When I > run my code I end up adding the route to TR1 via area 0 since it's the > same > cost as across area 1. As a result of this my virtual link never > comes up > because it does not know how to get to TR1 from area 1. Could you please > point me to the section in RFC 2328 that deals with this case? While it may not be obvious, the first paragraph on page 109 covers this case: The set of paths to use for a destination may vary base on the OSPF area to which the paths belong. This means that there may be multiple routing table entries for the same destination, depending on the values of the next field. As far as implementation, I recommend you maintain a separate per-area routing table for routers. > > Thanks for your time. > > Regards, > Archana > > _________________________________________________________________ > Send instant messages to anyone on your contact list with MSN Messenger > 6.0. Try it now FREE! http://msnmessenger-download.com > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 00:27:04 2003 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 AAA12246 for ; Tue, 28 Oct 2003 00:27:03 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C28EA2@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 0:27:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58895403 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 00:27:12 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 00:17:11 -0400 Received: from kailash1.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Tue, 28 Oct 2003 10:49:52 +0530 Received: from vanitha (vanitha.future.futsoft.com [10.6.4.92]) by kailash1.future.futsoft.com (8.11.0/8.11.0) with SMTP id h9S5DgT13560 for ; Tue, 28 Oct 2003 10:43:42 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Message-ID: <001001c39d12$d72f9da0$5c04060a@future.futsoft.com> Date: Tue, 28 Oct 2003 10:47:53 +0530 Reply-To: Mailing List Sender: Mailing List From: Vanitha N Subject: Re: Opaque LSA question: attaching OSPF interface to different area To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F9D338A.7010003@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Alex, Alex Levit wrote: >Hi All, > >Does anyone know about any specification what is to be done to Opaque LSA >type 9 (or 10) >when an OSPF interface through which it was originated is attached to area >different than it was >at the originating time? > For type 9, it is obvious the initial LSA should be purged and a new one originated. For type 10, the LSA is associated with an area as opposed to an interface. If the contents of the LSA are specific to the interface that has been moved to a different area (e.g., a TE LSA containing a link TLV), then the LSA should be purged from its former area and originated in the new area. >>> Why should we generate the Type9 LSA. Its scope is only interface. What do we gain by regenerating the LSA with the same contents. It is enough if the database synchronization takes care about flooding the original LSA during adjacency reformation. I agree with Type 10 LSA that if the contents of the LSA are specific to the interface (TE), we need to regenerate the TE Link in new area. But if the Type10 LSA is from some other application for the old area, it should not be regenerated. > >The LSA probably needs to be altered and re-originated, but does it making >any sense that OSPF will do the job itself >or the opaque application needs to be involved here? > Whether it needs to get involved or not, the LSA purge/originations should be signaled to the opaque application. > >Does it matter if interface was brought down and then up after reattaching >to new area? > I'd say "no" - from the perspective of OSPF it is a different interface. > >Thanks, >Alex > > > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 09:29:08 2003 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 JAA23375 for ; Tue, 28 Oct 2003 09:29:07 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C29759@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 9:29:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58947974 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 09:29:14 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 09:29:13 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8BE1318BF76 for ; Tue, 28 Oct 2003 06:29:12 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12188-01 for ; Tue, 28 Oct 2003 06:29:12 -0800 (PST) Received: from redback.com (pptp-6-129.redback.com [155.53.6.129]) by prattle.redback.com (Postfix) with ESMTP id 9F12C18BF71 for ; Tue, 28 Oct 2003 06:29:11 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <001001c39d12$d72f9da0$5c04060a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F9E7D2A.5060709@redback.com> Date: Tue, 28 Oct 2003 09:28:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Opaque LSA question: attaching OSPF interface to different area To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <001001c39d12$d72f9da0$5c04060a@future.futsoft.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Vanitha, Please configure you're E-mail client to quote your reply so that is it easy to see what you've said. Vanitha N wrote: >Hi Alex, > >Alex Levit wrote: > > > >>Hi All, >> >>Does anyone know about any specification what is to be done to Opaque LSA >>type 9 (or 10) >>when an OSPF interface through which it was originated is attached to area >>different than it was >>at the originating time? >> >> >> >For type 9, it is obvious the initial LSA should be purged and a new >one originated. For type 10, >the LSA is associated with an area as opposed to an interface. If the >contents of the LSA are >specific to the interface that has been moved to a different area (e.g., >a TE LSA containing a >link TLV), then the LSA should be purged from its former area and >originated in the new area. > > > > >>>>Why should we generate the Type9 LSA. Its scope is only interface. What >>>> >>>> >do we gain by regenerating the LSA with the same contents. It is enough if >the database synchronization takes care about flooding the original LSA >during adjacency reformation. > It is true that there is nothing in the contents of the LSA specific to the area and you could avoid regeneratting the LSA internally. However, the flooding will be the same since the scope is interface. It is much simpler conceptually to treat the move from one area to another as an interface deletion and creation. > >I agree with Type 10 LSA that if the contents of the LSA are specific to the >interface (TE), we need to regenerate the TE Link in new area. >But if the Type10 LSA is from some other application for the old area, it >should not be regenerated. > I believe this is the corollary of what I said. > > > > > > > >>The LSA probably needs to be altered and re-originated, but does it making >>any sense that OSPF will do the job itself >>or the opaque application needs to be involved here? >> >> >> >Whether it needs to get involved or not, the LSA purge/originations >should be signaled to the opaque >application. > > > > >>Does it matter if interface was brought down and then up after reattaching >>to new area? >> >> >> >I'd say "no" - from the perspective of OSPF it is a different interface. > > > >>Thanks, >>Alex >> >> >> >> >> > > > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 09:36:15 2003 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 JAA24387 for ; Tue, 28 Oct 2003 09:36:15 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C2957D@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 9:36:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58947871 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 09:36:22 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 09:26:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23074; Tue, 28 Oct 2003 09:26:10 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200310281426.JAA23074@ietf.org> Date: Tue, 28 Oct 2003 09:26:10 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mib-update-07.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF Version 2 Management Information Base Author(s) : S. Giacalone, D. Joyal, R. Coltun, F. Baker Filename : draft-ietf-ospf-mib-update-07.txt Pages : 107 Date : 2003-10-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. This memo is intended to update and possibly obsolete RFC 1850, however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1580 are explained in Appendix B. Please send comments to ospf@discuss.microsoft.com. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mib-update-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-mib-update-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28094649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mib-update-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mib-update-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28094649.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 11:04:18 2003 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 LAA03438 for ; Tue, 28 Oct 2003 11:04:17 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C2987D@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 11:04:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58953771 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 11:04:24 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 11:04:24 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E3EBA3A9E2C for ; Tue, 28 Oct 2003 08:04:22 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23596-05 for ; Tue, 28 Oct 2003 08:04:22 -0800 (PST) Received: from redback.com (pptp-6-129.redback.com [155.53.6.129]) by prattle.redback.com (Postfix) with ESMTP id 032BA3A9E2A for ; Tue, 28 Oct 2003 08:04:22 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050004000906020505030105" Message-ID: <3F9E9379.3070602@redback.com> Date: Tue, 28 Oct 2003 11:04:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------050004000906020505030105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit There has been some discussion of this draft off-list and I decided it time to bring to the list rather than continue with multiple off-list e-mail threads. Here are the issues as I see them. 1. Should OSPF be used for tunnel auto-configuration? The arguments for this are that OSPF is used for TE and this is yet another opaque application. Additionally, one proposed TE application (mesh group) is related to auto-configuration. The arguments against is that we must be very careful what we put in the IGP. I don't feel that strongly one way or another here. The thing about this application is that it doesn't really modify any basic OSPF mechanisms so it only has impact on the OSPF routing domain if it is used. My biggest fear would be that if this draft is accepted it would only be the first of a torrent of auto-configuration drafts. 2. If the answer to #1 is yes, do we want to use the OSPF capability opaque LSA? As an author of the capabilities draft, I'd say "no" since there is a variable amount of information that may be advertised and we don't want to make the capabilities LSA an all purpose container for multitudes of TLVs. Rather it is meant to contain the router's overall capabilities and possibily a sub-TLV or two describing the a capability. While the techniques for concatenating LSAs are well-known, there really isn't any advantage here of stuffing all the local tunnel endpoints into the capabilities LSA. In short, if this application is worth doing it is worth allocating an opaque LSA type (and OSPFv3 LSA type) for it. 3. Percisely how will the opaque LSA be used? When will the tunnel be created, deleted, brought up/down? How does tunnel group ID come into play? Must there be OSPF connectivity for the tunnel to be considered up or will any type of route do? I believe the authors are in agreement that more specification is needed for this to be a viable draft that would facilitate interoperable implementations. Thanks, Acee --------------050004000906020505030105 Content-Type: text/plain; name="draft-eng-nalawade-ospf-tunnel-cap-00.txt" Content-Disposition: inline; filename="draft-eng-nalawade-ospf-tunnel-cap-00.txt" Content-Transfer-Encoding: 7bit Network Working Group Sandy Eng Internet Draft Gargi Nalawade Expires: March 2004 Peter Psenak Cisco Systems OSPF Tunnel capability TLVs draft-eng-nalawade-ospf-tunnel-cap-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As increasing number of tunnels are deployed in a Provider core, there is a need for improving the efficiency and ease of tunnel establishment. OSPF running as the IGP in a Provider core, can act as the signalling agent for the Tunnel endpoints. OSPF can carry tunnel endpoint information in the intra-AS scope, easing BGP of the extra burden of signalling within the core. 1. Introduction draft-eng-nalawade-ospf-tunnel-00.txt [Page 1] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 Two end-points of a Tunnel need to know the end-point information and its binding to a network address at the remote point. Normally, this can be statically shared and configured. But in case of a large network where there may be a need for a large number of tunnels. The number of tunnel end-points that would need to be configured and maintained soon becomes unmanageable. This draft proposes using OSPF for signalling the Tunnel endpoints and introdcues an OSPF IPv4 tunnel capability TLV that will be carried within the OSPF router information LSA. 2. Specification This document defines a Tunnel TLV to be carried in the OSPF Router Information LSA. The Tunnel Information TLV has a type of 4. The first twelve bytes contain the following : - Address Type (2 octects) - Reserved (6 octects) - Tunnel endpoint address (4 or 16 octects) - Tunnel ID (2 Octets) - Tunnel-Group ID (2 Octets) This is followed by tunnel sub-TLVs which MUST be included. The Tunnel TLV looks as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel endpoint address (4 - 16 octects) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID (2 octects) | Tunnel-Group ID (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | sub-TLV(s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-eng-nalawade-ospf-tunnel-00.txt [Page 2] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 where Type: identifies the Tunnel TLV type and will have a value of 4 Length: length of the value field in octets Address Type : defines the Address-Type used as defined for AFIs by [9] Tunnel endpoint address : is a 4-octet address for the IPv4 Tunnel TLV and 16-octet for the IPv6 Tunnel TLV. Tunnel ID : is a 2-octet identifier to identify a Tunnel endpoint Tunnel-Group ID : is a 2-octet global group Identifier used by all PE endpoints who are interested in establishing tunnel relationships with each other. sub-TLVs : will contain Tunnel encapsulation sub-TLVs. Eg. 1 : L2TPv3 Tunnel information 2 : mGRE Tunnel information 3 : IPSec Tunnel information 4 : MPLS Tunnel information 2.1. OSPF L2TPv3 tunnel sub-TLV The L2TPv3 Tunnel Information TLV has a type value of 1. The value part of the L2TPv3 Tunnel Information Type contains the following : - Preference (2 Octets) - Flags (1 Octet) - Cookie Length (1 Octet) - Session ID (4 Octets) - Cookie (Variable) The L2TPv3 Tunnel sub-TLV looks as follows : draft-eng-nalawade-ospf-tunnel-00.txt [Page 3] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type = 1 | Length (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference (2 octects) |S| Flags | Cookie Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID (4 Octects) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie (Variable, 0 or 8 octexts) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Length : is a multiple of 4 octects. Preference : is a 2-octet field containing a Preference associated with the TLV. The Preference value indicates a preferred ordering of tunneling encapsulations according to the sender. The recipient of the information SHOULD take the sender's preference into account in selecting which encapsulation it will use. A higher value indicates a higher preference. Flags : is a 1-octet field containing flag-bits. The leftmost bit indicates whether Sequence numbering is to be used or not. The remaining bits are reserved for future use. Cookie Length : is a 1-octet field that contains the length of the variable length Cookie. Session ID : is a 4-octet field containing a non-zero identifier for a session. Cookie : is a variable length (maximum 64 bits), value used by L2TPv3 to check the association of a received data message with the session identified by the Session ID. 2.2. OSPF mGRE Tunnel sub-TLV The OSPF mGRE Tunnel sub-TLV has a type value of 2. The value part of the mGRE Tunnel Information Type contains the following : draft-eng-nalawade-ospf-tunnel-00.txt [Page 4] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 - Preference (2 Octets) - Flags (1 Octet) - mGRE Key (0 or 4 Octets) The mGRE Tunnel sub-TLV looks as follows : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type = 2 | Length (8 octects) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference (2 octects) |S|K| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mGRE Key (4 Octects) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Length : is 8 octets. Preference : is a 2-octet field containing a Preference associated with the TLV. The Preference value indicates a preferred ordering of tunneling encapsulations according to the sender. The recipient of the information SHOULD take the sender's preference into account in selecting which encapsulation it will use. A higher value indicates a higher preference. Flags : is 1-octet field containing flag-bits. The leftmost bit indicates whether Sequence numbering is to be used or not. The 2nd bit indicates whether an mGRE Key is present or not. The remaining bits are reserved for future use. mGRE Key : A 4-octet field containing an optional mGRE Key. 3. Operation A router must originate a new OSPF router information LSA whenever the content of the Tunnel TLV changes or whenever required by the regular OSPF procedure (LSA refresh (every LSRefreshTime, ...)). The Tunnel TLV may be carried within either a type 10 or 11 router information LSA. As defined in RFC2370, an opaque LSA has a flooding scope determined by its LSA type: draft-eng-nalawade-ospf-tunnel-00.txt [Page 5] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 - area-local (type 10) - entire OSPF routing domain (type 11) If all Tunnel endpoints lie within a single area, a type 10 router infomation LSA must be generated. If the Tunnel endpoints span multiple OSPF areas, a type 11 router information LSA must be generated. 4. Deployment Considerations and Interoperability In an IP VPN environment, this specification does not require any provider core routers to be upgraded. Only routers who are interested to be tunnel endpoints are required to understand this specification. This poses no backward compatibility issue as routers which do not understand this specification will simply ignore the TLVs. 5. Security Considerations This extension to OSPF does not change the underlying security issues. 6. Acknowledgements The authors would like to thank Steven Luong, Raja Daoud, Dan Tappan, Jean-Phillip Vasseur and Eric Rosen for their inputs and comments. 7. References [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. . [2] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-04.txt [3] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998 [4] Aggarwal et all, ''Extensions to IS-IS and OSPF for Advertising Optional Router Capabilities'', Internet draft, draft-raggarwa-igp- cap-01.txt, October 2002. [5] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP- 4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. draft-eng-nalawade-ospf-tunnel-00.txt [Page 6] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 [6] Nalawade G., Kapoor R., Tappan D., "BGP IPv4-Tunnel SAFI", draft-nalawade-kapoor-tunnel-safi-00.txt, work in progress. [7] Bates et al, Multiprotocol Extensions for BGP-4, draft- ietf- idr-rfc2858bis-02.txt, work in progress. [8] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [9] http://www.iana.org/assignments/address-family-numbers 8. Authors' Addresses Sandy Eng mailto:swkeng@cisco.com Gargi Nalawade mailto:gargi@cisco.com Peter Psenak mailto:ppsenak@cisco.com Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95134 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. draft-eng-nalawade-ospf-tunnel-00.txt [Page 7] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." draft-eng-nalawade-ospf-tunnel-00.txt [Page 8] --------------050004000906020505030105-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 12:55:34 2003 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 MAA12924 for ; Tue, 28 Oct 2003 12:55:33 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C299A3@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 12:55:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58961663 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 12:55:39 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 12:55:39 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9SHtZQY005483 for ; Tue, 28 Oct 2003 09:55:35 -0800 (PST) Received: from cisco.com (sjc-vpn3-349.cisco.com [10.21.65.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANP34824; Tue, 28 Oct 2003 09:55:33 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F9EAD95.9050101@cisco.com> Date: Tue, 28 Oct 2003 09:55:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Continuing our discussion, and reiterating some points we had made - Acee Lindem wrote: > There has been some discussion of this draft off-list and I decided it > time to bring to the list rather than continue with multiple off-list > e-mail threads. > > Here are the issues as I see them. > > 1. Should OSPF be used for tunnel auto-configuration? > > The arguments for this are that OSPF is used for TE and > this is yet another opaque application. Additionally, one > proposed TE application (mesh group) is related to > auto-configuration. > > The arguments against is that we must be very careful what > we put in the IGP. > > I don't feel that strongly one way or another here. The thing > about this application is that it doesn't really modify any > basic OSPF mechanisms so it only has impact on the OSPF routing > domain if it is used. > > My biggest fear would be that if this draft is accepted it > would only be the first of a torrent of auto-configuration > drafts. We are not just dealing with auto-configuration here, but announcing a unique capability a router has for a specific tunnel type. Applications which use this capability can then take respective actions. > > 2. If the answer to #1 is yes, do we want to use the OSPF capability > opaque LSA? > > As an author of the capabilities draft, I'd say "no" since there > is a variable amount of information that may be advertised and we > don't want to make the capabilities LSA an all purpose container for > multitudes of TLVs. Rather it is meant to contain the router's > overall capabilities and possibily a sub-TLV or two describing The draft is describing exactly this. We are not over stuffing the TLV with more than one or two sub-TLV(s) per PE announing the capability. Thanks, Sandy > the a capability. While the techniques for concatenating LSAs > are well-known, there really isn't any advantage here of stuffing > all the local tunnel endpoints into the capabilities LSA. > > In short, if this application is worth doing it is worth allocating > an opaque LSA type (and OSPFv3 LSA type) for it. > > > 3. Percisely how will the opaque LSA be used? When will the tunnel be > created, deleted, brought up/down? How does tunnel group ID come > into play? Must there be OSPF connectivity for the tunnel to be > considered up or will any type of route do? > > > I believe the authors are in agreement that more specification is > needed for this to be a viable draft that would facilitate > interoperable implementations. > > > Thanks, > Acee > > > ------------------------------------------------------------------------ > > > > > > > > Network Working Group Sandy Eng > Internet Draft Gargi Nalawade > Expires: March 2004 Peter Psenak > Cisco Systems > > > > OSPF Tunnel capability TLVs > > draft-eng-nalawade-ospf-tunnel-cap-00.txt > > > > Status of this Memo > > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > Abstract > > As increasing number of tunnels are deployed in a Provider core, > there is a need for improving the efficiency and ease of tunnel > establishment. OSPF running as the IGP in a Provider core, can act > as the signalling agent for the Tunnel endpoints. OSPF can carry > tunnel endpoint information in the intra-AS scope, easing BGP of the > extra burden of signalling within the core. > > > 1. Introduction > > > > > draft-eng-nalawade-ospf-tunnel-00.txt [Page 1] > > > > > > Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 > > > Two end-points of a Tunnel need to know the end-point information and > its binding to a network address at the remote point. Normally, this > can be statically shared and configured. But in case of a large > network where there may be a need for a large number of tunnels. The > number of tunnel end-points that would need to be configured and > maintained soon becomes unmanageable. This draft proposes using OSPF > for signalling the Tunnel endpoints and introdcues an OSPF IPv4 > tunnel capability TLV that will be carried within the OSPF router > information LSA. > > 2. Specification > > This document defines a Tunnel TLV to be carried in the OSPF Router > Information LSA. > > The Tunnel Information TLV has a type of 4. The first twelve bytes > contain the following : > > > - Address Type (2 octects) > - Reserved (6 octects) > - Tunnel endpoint address (4 or 16 octects) > - Tunnel ID (2 Octets) > - Tunnel-Group ID (2 Octets) > > > This is followed by tunnel sub-TLVs which MUST be included. > > The Tunnel TLV looks as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 4 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address Type | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tunnel endpoint address (4 - 16 octects) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tunnel ID (2 octects) | Tunnel-Group ID (2 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | sub-TLV(s) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > draft-eng-nalawade-ospf-tunnel-00.txt [Page 2] > > > > > > Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 > > > where > > Type: identifies the Tunnel TLV type and will have a value of 4 > > Length: length of the value field in octets > > Address Type : defines the Address-Type used as defined for AFIs by > [9] > > Tunnel endpoint address : is a 4-octet address for the IPv4 Tunnel > TLV and 16-octet for the IPv6 Tunnel TLV. > > Tunnel ID : is a 2-octet identifier to identify a Tunnel endpoint > > Tunnel-Group ID : is a 2-octet global group Identifier used by all PE > endpoints who are interested in establishing tunnel relationships > with each other. > > sub-TLVs : will contain Tunnel encapsulation sub-TLVs. Eg. > > 1 : L2TPv3 Tunnel information > > 2 : mGRE Tunnel information > > 3 : IPSec Tunnel information > > 4 : MPLS Tunnel information > > > > 2.1. OSPF L2TPv3 tunnel sub-TLV > > The L2TPv3 Tunnel Information TLV has a type value of 1. The value > part of the L2TPv3 Tunnel Information Type contains the following : > > > - Preference (2 Octets) > - Flags (1 Octet) > - Cookie Length (1 Octet) > - Session ID (4 Octets) > - Cookie (Variable) > > > > > The L2TPv3 Tunnel sub-TLV looks as follows : > > > > > > draft-eng-nalawade-ospf-tunnel-00.txt [Page 3] > > > > > > Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-Type = 1 | Length (Variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Preference (2 octects) |S| Flags | Cookie Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Session ID (4 Octects) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Cookie (Variable, 0 or 8 octexts) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > where > > Length : is a multiple of 4 octects. > > Preference : is a 2-octet field containing a Preference associated > with the TLV. The Preference value indicates a preferred ordering of > tunneling encapsulations according to the sender. The recipient of > the information SHOULD take the sender's preference into account in > selecting which encapsulation it will use. A higher value indicates a > higher preference. > > Flags : is a 1-octet field containing flag-bits. The leftmost bit > indicates whether Sequence numbering is to be used or not. The > remaining bits are reserved for future use. > > Cookie Length : is a 1-octet field that contains the length of the > variable length Cookie. > > Session ID : is a 4-octet field containing a non-zero identifier for > a session. > > Cookie : is a variable length (maximum 64 bits), value used by L2TPv3 > to check the association of a received data message with the session > identified by the Session ID. > > > > 2.2. OSPF mGRE Tunnel sub-TLV > > The OSPF mGRE Tunnel sub-TLV has a type value of 2. The value part > of the mGRE Tunnel Information Type contains the following : > > > > > > draft-eng-nalawade-ospf-tunnel-00.txt [Page 4] > > > > > > Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 > > > - Preference (2 Octets) > - Flags (1 Octet) > - mGRE Key (0 or 4 Octets) > > > > The mGRE Tunnel sub-TLV looks as follows : > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-Type = 2 | Length (8 octects) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Preference (2 octects) |S|K| Flags | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | mGRE Key (4 Octects) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > where > > Length : is 8 octets. > > Preference : is a 2-octet field containing a Preference associated > with the TLV. The Preference value indicates a preferred ordering of > tunneling encapsulations according to the sender. The recipient of > the information SHOULD take the sender's preference into account in > selecting which encapsulation it will use. A higher value indicates a > higher preference. > > Flags : is 1-octet field containing flag-bits. The leftmost bit > indicates whether Sequence numbering is to be used or not. The 2nd > bit indicates whether an mGRE Key is present or not. The remaining > bits are reserved for future use. > > mGRE Key : A 4-octet field containing an optional mGRE Key. > > > 3. Operation > > A router must originate a new OSPF router information LSA whenever > the content of the Tunnel TLV changes or whenever required by the > regular OSPF procedure (LSA refresh (every LSRefreshTime, ...)). > > The Tunnel TLV may be carried within either a type 10 or 11 router > information LSA. As defined in RFC2370, an opaque LSA has a flooding > scope determined by its LSA type: > > > > draft-eng-nalawade-ospf-tunnel-00.txt [Page 5] > > > > > > Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 > > > - area-local (type 10) > - entire OSPF routing domain (type 11) > > > > If all Tunnel endpoints lie within a single area, a type 10 router > infomation LSA must be generated. > > If the Tunnel endpoints span multiple OSPF areas, a type 11 router > information LSA must be generated. > > > 4. Deployment Considerations and Interoperability > > In an IP VPN environment, this specification does not require any > provider core routers to be upgraded. Only routers who are interested > to be tunnel endpoints are required to understand this specification. > This poses no backward compatibility issue as routers which do not > understand this specification will simply ignore the TLVs. > > > 5. Security Considerations > > This extension to OSPF does not change the underlying security > issues. > > > 6. Acknowledgements > > The authors would like to thank Steven Luong, Raja Daoud, Dan Tappan, > Jean-Phillip Vasseur and Eric Rosen for their inputs and comments. > > > 7. References > > [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. . > > [2] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", > draft-katz-yeung-ospf-traffic-04.txt > > [3] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998 > > [4] Aggarwal et all, ''Extensions to IS-IS and OSPF for Advertising > Optional Router Capabilities'', Internet draft, draft-raggarwa-igp- > cap-01.txt, October 2002. > > [5] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP- > 4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. > > > > draft-eng-nalawade-ospf-tunnel-00.txt [Page 6] > > > > > > Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 > > > [6] Nalawade G., Kapoor R., Tappan D., "BGP IPv4-Tunnel SAFI", > draft-nalawade-kapoor-tunnel-safi-00.txt, work in progress. > > [7] Bates et al, Multiprotocol Extensions for BGP-4, draft- ietf- > idr-rfc2858bis-02.txt, work in progress. > > [8] Kent, S., and R. Atkinson, "Security Architecture for the > Internet Protocol", RFC 2401, November 1998. > > [9] http://www.iana.org/assignments/address-family-numbers > > 8. Authors' Addresses > > Sandy Eng mailto:swkeng@cisco.com > > Gargi Nalawade mailto:gargi@cisco.com > > Peter Psenak mailto:ppsenak@cisco.com > > Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95134 > > > 9. Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards- related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementers or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > > 10. Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > > > draft-eng-nalawade-ospf-tunnel-00.txt [Page 7] > > > > > > Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 > > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. The limited permissions granted above are perpetual and > will not be revoked by the Internet Society or its successors or > assigns. This document and the information contained herein is > provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE > INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > draft-eng-nalawade-ospf-tunnel-00.txt [Page 8] > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 13:18:15 2003 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 NAA14283 for ; Tue, 28 Oct 2003 13:18:15 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C29C44@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 13:18:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58962759 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 13:18:23 -0500 Received: from 144.254.74.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 13:08:23 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2003 19:06:16 +0100 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9SI8Jiw004612 for ; Tue, 28 Oct 2003 10:08:19 -0800 (PST) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMY64044; Tue, 28 Oct 2003 10:06:24 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F9EB092.7070105@cisco.com> Date: Tue, 28 Oct 2003 10:08:18 -0800 Reply-To: Mailing List Sender: Mailing List From: Gargi Nalawade Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Acee Lindem wrote: > There has been some discussion of this draft off-list and I decided it > time to bring to the list rather than continue with multiple off-list > e-mail threads. > > Here are the issues as I see them. > > 1. Should OSPF be used for tunnel auto-configuration? > > The arguments for this are that OSPF is used for TE and > this is yet another opaque application. Additionally, one > proposed TE application (mesh group) is related to > auto-configuration. > > The arguments against is that we must be very careful what > we put in the IGP. > > I don't feel that strongly one way or another here. The thing > about this application is that it doesn't really modify any > basic OSPF mechanisms so it only has impact on the OSPF routing > domain if it is used. > > My biggest fear would be that if this draft is accepted it > would only be the first of a torrent of auto-configuration > drafts. You mean second :) Let me point out though that this isnt a new application. The basic application is a customer-driven requirement for advertising tunnel capabilities and info. The config-reduction is a by-product of that. Also, this is simply a generalized mechanism for advertising the tunnel capabilties. > > 2. If the answer to #1 is yes, do we want to use the OSPF capability > opaque LSA? > > As an author of the capabilities draft, I'd say "no" since there > is a variable amount of information that may be advertised and we > don't want to make the capabilities LSA an all purpose container for > multitudes of TLVs. Rather it is meant to contain the router's > overall capabilities and possibily a sub-TLV or two describing > the a capability. While the techniques for concatenating LSAs That is exactly what it is used for by this draft as well. To advertise the Tunnels capability set to the peers. > are well-known, there really isn't any advantage here of stuffing > all the local tunnel endpoints into the capabilities LSA. > > In short, if this application is worth doing it is worth allocating > an opaque LSA type (and OSPFv3 LSA type) for it. > > > 3. Percisely how will the opaque LSA be used? When will the tunnel be > created, deleted, brought up/down? How does tunnel group ID come > into play? Must there be OSPF connectivity for the tunnel to be > considered up or will any type of route do? > Most of this is implementation-specific really. But to answer your last question, there needs to be connectivity for the tunnel to be considered up. -Gargi > > I believe the authors are in agreement that more specification is > needed for this to be a viable draft that would facilitate > interoperable implementations. > > > Thanks, > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 13:44:02 2003 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 NAA15901 for ; Tue, 28 Oct 2003 13:44:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C29CF5@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 13:44:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58965440 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 13:44:08 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 13:44:08 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2003 10:42:47 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9SIi5jP015781; Tue, 28 Oct 2003 10:44:05 -0800 (PST) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMY69275; Tue, 28 Oct 2003 10:42:10 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F9EB8F2.10002@cisco.com> Date: Tue, 28 Oct 2003 19:44:02 +0100 Reply-To: Mailing List Sender: Mailing List From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F9EAD95.9050101@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, > My biggest fear would be that if this draft is accepted it > would only be the first of a torrent of auto-configuration > drafts. Second one not first ;). Notice this one submitted a while back: draft-raszuk-ospf-bgp-peer-discovery-00.txt > 1. Should OSPF be used for tunnel auto-configuration? I think in general this requires a study on a case by case basis. Most important factors which should be taken into consideration are: *A* How frequently the information advertised changed - is it static configuration or dynamic in nature which triggers reflooding ? *B* Is the application which the uses delivered information limited to IGP domain or crosses domains ? *C* What is the amount of information to be flooded (keeping in mind that majority of P routers - those in the core - will never use it. *D* What are the alternatives available & _deployed_ today to deliver the same information to it's users *E* How often area wide flooding will be sufficient versus domain wide. Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the following: Reg A: Info is essentially static except the L2TPv3 cookie rollover intervals which if implementation permits could be changing periodically Reg B: I think that in any application of tunnels we can't limit the scope of use to one IGP domain. There can be a lot of customers who may never need to go over a domain (which this draft is targeting though). Reg C: Minimal (comparing to TE at least :):). Reg D: It is worth noting that there is a few drafts in IDR describing the ideas for the same information distribution Reg E: Looking at the most common OSPF topologies I would say that most tunnels will be build between edge PEs and those in a lot of cases are located in it's own POP areas. Not to say that there are no customers who keep most of their PEs on the edges of area 0. Rgs, R. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 19:56:54 2003 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 TAA12983 for ; Tue, 28 Oct 2003 19:56:53 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C2A678@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 19:57:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58999553 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 19:57:00 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 19:57:00 -0400 Received: (qmail 21647 invoked by uid 404); 29 Oct 2003 00:57:00 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.030972 secs); 29 Oct 2003 00:57:00 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 29 Oct 2003 00:57:00 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id TAA11715; Tue, 28 Oct 2003 19:56:59 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200310290056.TAA11715@bigbird.nj.us.utstar.com> Date: Tue, 28 Oct 2003 19:56:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: last call draft-ietf-l3vpn-ospf-2547-00.txt (fwd) Comments: cc: rcallon@juniper.net To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Please comments on the ospf or l3vpn lists with CC to authors. --rohit. ------- Forwarded Message >Date: Tue, 28 Oct 2003 08:57:53 -0500 >To: l3vpn@ietf.org, ospf@peach.ease.lsoft.com >From: Ross Callon >Subject: last call draft-ietf-l3vpn-ospf-2547-00.txt > >This begins the working group last call on: > > OSPF as the PE/CE Protocol in BGP/MPLS VPNs > draft-ietf-l3vpn-ospf-2547-00.txt > >While this document is an l3vpn working group document, >the last call will take place on both the l3vpn and ospf working >group mailing lists. The last call will terminate at the end of the >day on Friday November 14th. > >Thanks, Ross ------- End of Forwarded Message From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 28 20:31:48 2003 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 UAA14919 for ; Tue, 28 Oct 2003 20:31:47 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C2A5E3@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 20:31:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59001872 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 20:31:50 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 20:31:50 -0400 Received: (qmail 24125 invoked by uid 404); 29 Oct 2003 01:31:50 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.369481 secs); 29 Oct 2003 01:31:50 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 29 Oct 2003 01:31:49 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id UAA11879; Tue, 28 Oct 2003 20:31:49 -0500 Message-ID: <200310290131.UAA11879@bigbird.nj.us.utstar.com> Date: Tue, 28 Oct 2003 20:31:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists Comments: cc: ronald.p.bonica@mci.com, rick@rhwilder.net, rcallon@juniper.net, erosen@cisco.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is the start of a Working Group last call for "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs" (draft-ietf-ospf-2547-dnbit-01.txt) All comments should be received by 5PM (US Eastern), 11/14/2003. Please send your comments to the OSPF list. The draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ospf-2547-dnbit-01.txt This is a companion document to draft-ietf-l3vpn-ospf-2547-00.txt which is also in Last Call. Both of these documents are being Last Called in OSPF WG as well as the L3VPN WG. --rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 29 09:41:00 2003 Received: from LIME.ease.lsoft.com (lime.ease.lsoft.com [209.119.0.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09492 for ; Wed, 29 Oct 2003 09:41:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0001FDC0@LIME.ease.lsoft.com>; Wed, 29 Oct 2003 9:37:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59091154 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 29 Oct 2003 09:41:06 -0500 Received: from 62.241.160.193 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 29 Oct 2003 09:41:06 -0400 Received: from tom3 (1Cust48.tnt6.lnd4.gbr.da.uu.net [62.188.135.48]) by pengo.systems.pipex.net (Postfix) with SMTP id 896B74C007D8 for ; Wed, 29 Oct 2003 14:41:04 +0000 (GMT) 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <005601c39e2a$42de8440$0301a8c0@tom3> Date: Wed, 29 Oct 2003 12:36:30 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Any chance of extending that date of 14Nov by a week? Realistically, the next two and a bit weeks are already full and I suspect I am not alone in that - post 14Nov is a different story. Tom Petch -----Original Message----- From: Rohit Dube To: OSPF@PEACH.EASE.LSOFT.COM Date: 29 October 2003 01:31 Subject: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists >This is the start of a Working Group last call for >"Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs" >(draft-ietf-ospf-2547-dnbit-01.txt) >All comments should be received by 5PM (US Eastern), 11/14/2003. >Please send your comments to the OSPF list. > >The draft can be found at >http://www.ietf.org/internet-drafts/draft-ietf-ospf-2547-dnbit-01.txt >This is a companion document to draft-ietf-l3vpn-ospf-2547-00.txt >which is also in Last Call. Both of these documents are being Last Called >in OSPF WG as well as the L3VPN WG. > >--rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 29 11:21:12 2003 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 LAA17038 for ; Wed, 29 Oct 2003 11:21:11 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C2B831@cherry.ease.lsoft.com>; Wed, 29 Oct 2003 11:21:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59098653 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 29 Oct 2003 11:21:18 -0500 Received: from 47.129.242.157 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 29 Oct 2003 11:21:16 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9TGLEc28782 for ; Wed, 29 Oct 2003 11:21:14 -0500 (EST) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Oct 2003 11:21:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39E38.A8F8ACD4" Message-ID: <6204FDDE129D364D8040A98BCCB290EF05DD920E@zbl6c004.corpeast.baynetworks.com> Date: Wed, 29 Oct 2003 11:21:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: OSPFv2 MIB update Comments: cc: Piotr Galecki 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_01C39E38.A8F8ACD4 Content-Type: text/plain Revision -07 of draft-ietf-ospf-mib-update has been posted. It includes the following changes from revision -06. - added object ospfDiscontinuityTime in order for a management entity to detect counter discontinuity events - updated REVISION DESCRIPTION clauses with description of major MIB modifications - updated MIB contact info - moved all relevant MIB comments to objects' DESCRIPTION clauses - added reason for object deprecation in DESCRIPTION clause - added persistence information for read-write, read-create objects - described conditions when columns can be modified in RowStatus managed rows as required by RFC 2579 - defined 'OspfAuthType' TC and modified authentication type objects to use the new type - Removed InterfaceIndex TC because it conflicts with TC in IF-MIB - made index objects of new tables not-accessible ( index objects of old tables remain read-only ) - added the UNITS clause to several objects - added ospfIfDesignatedRouterId and ospfIfBackupDesignatedRouterId to the OspfIfEntry - added the area LSA counter table - ospfAreaLsaCountTable - Removed ospfTrafficEngineeringSupport general group object. WG consensus was that a separate OSPF TE MIB should be defined. - restored MAX-ACCESS value of ospfHostAreaID to read-only (RFC 1850). MIB rules do not allow MAX-ACCESS to be changed on an object. - added new Host Table object ospfHostCfgAreaID to allow configuration of AreaID. - added Intellectual Property Rights section - added latest MIB boilerplate sections - updated WG e-mail list - indicate in abstract that the MIB is specific to IPv4 - changed references from "hitless" restart to "graceful" restart - added section 1.5 describing reference for implementing MIB views on multiple OSPF instances - new page number format in footer Piotr and Dan ------_=_NextPart_001_01C39E38.A8F8ACD4 Content-Type: text/html OSPFv2 MIB update

Revision -07 of draft-ietf-ospf-mib-update has
been posted. It includes the following changes
from revision -06.
 
- added object ospfDiscontinuityTime in order for a management entity
  to detect counter discontinuity events
- updated REVISION DESCRIPTION clauses with description of major MIB
  modifications
- updated MIB contact info
- moved all relevant MIB comments to objects' DESCRIPTION clauses
- added reason for object deprecation in DESCRIPTION clause
- added persistence information for read-write, read-create objects
- described conditions when columns can be modified in RowStatus
  managed rows as required by RFC 2579
- defined 'OspfAuthType' TC and modified authentication type objects
  to use the new type
- Removed InterfaceIndex TC because it conflicts with TC in IF-MIB
- made index objects of new tables not-accessible ( index objects
  of old tables remain read-only )
- added the UNITS clause to several objects
- added ospfIfDesignatedRouterId and ospfIfBackupDesignatedRouterId
  to the OspfIfEntry
- added the area LSA counter table - ospfAreaLsaCountTable
- Removed ospfTrafficEngineeringSupport general group object. WG
  consensus was that a separate OSPF TE MIB should be defined.
- restored MAX-ACCESS value of ospfHostAreaID to read-only (RFC 1850).
  MIB rules do not allow MAX-ACCESS to be changed on an object.
- added new Host Table object ospfHostCfgAreaID to allow configuration
  of AreaID.
- added Intellectual Property Rights section
- added latest MIB boilerplate sections
- updated WG e-mail list
- indicate in abstract that the MIB is specific to IPv4
- changed references from "hitless" restart to "graceful" restart
- added section 1.5 describing reference for implementing
  MIB views on multiple OSPF instances
- new page number format in footer

 
Piotr and Dan

------_=_NextPart_001_01C39E38.A8F8ACD4-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 29 13:50:02 2003 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 NAA26501 for ; Wed, 29 Oct 2003 13:50:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C2BB84@cherry.ease.lsoft.com>; Wed, 29 Oct 2003 13:50:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59110479 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 29 Oct 2003 13:50:07 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 29 Oct 2003 13:50:07 -0400 Received: (qmail 24766 invoked by uid 404); 29 Oct 2003 18:50:07 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.023821 secs); 29 Oct 2003 18:50:07 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 29 Oct 2003 18:50:07 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id NAA25555; Wed, 29 Oct 2003 13:50:05 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200310291850.NAA25555@bigbird.nj.us.utstar.com> Date: Wed, 29 Oct 2003 13:50:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists Comments: cc: rcallon@juniper.net, rick@rhwilder.net, ronald.p.bonica@mci.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Message from Tom Petch of "Wed, 29 Oct 2003 12:36:30 GMT." <005601c39e2a$42de8440$0301a8c0@tom3> Precedence: list Hi Tom, Fair request. Let me re-schedule the deadline to 11/21/2003 5PM Eastern. --rohit. On Wed, 29 Oct 2003 12:36:30 -0000 Tom Petch writes: =>Any chance of extending that date of 14Nov by a week? => =>Realistically, the next two and a bit weeks are already full and I =>suspect I am not alone in that - post 14Nov is a different story. => =>Tom Petch From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 29 13:59:53 2003 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 NAA27042 for ; Wed, 29 Oct 2003 13:59:52 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C2BA0D@cherry.ease.lsoft.com>; Wed, 29 Oct 2003 14:00:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59110985 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 29 Oct 2003 13:59:59 -0500 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 29 Oct 2003 13:59:59 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 826CC1E4A3; Wed, 29 Oct 2003 13:59:55 -0500 (EST) Received: from [64.47.48.10] by xprdmailfe25.nwk.excite.com via HTTP; Wed, 29 Oct 2003 13:59:55 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20031029185955.826CC1E4A3@xmxpita.excite.com> Date: Wed, 29 Oct 2003 13:59:55 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: OSPFv2 MIB update To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Also, duplicateRouterId was added to the ospfConfigErrorType enumeration list. -don ================================================= Revision -07 of draft-ietf-ospf-mib-update has been posted. It includes the following changes from revision -06. - added object ospfDiscontinuityTime in order for a management entity to detect counter discontinuity events - updated REVISION DESCRIPTION clauses with description of major MIB modifications - updated MIB contact info - moved all relevant MIB comments to objects' DESCRIPTION clauses - added reason for object deprecation in DESCRIPTION clause - added persistence information for read-write, read-create objects - described conditions when columns can be modified in RowStatus managed rows as required by RFC 2579 - defined 'OspfAuthType' TC and modified authentication type objects to use the new type - Removed InterfaceIndex TC because it conflicts with TC in IF-MIB - made index objects of new tables not-accessible ( index objects of old tables remain read-only ) - added the UNITS clause to several objects - added ospfIfDesignatedRouterId and ospfIfBackupDesignatedRouterId to the OspfIfEntry - added the area LSA counter table - ospfAreaLsaCountTable - Removed ospfTrafficEngineeringSupport general group object. WG consensus was that a separate OSPF TE MIB should be defined. - restored MAX-ACCESS value of ospfHostAreaID to read-only (RFC 1850). MIB rules do not allow MAX-ACCESS to be changed on an object. - added new Host Table object ospfHostCfgAreaID to allow configuration of AreaID. - added Intellectual Property Rights section - added latest MIB boilerplate sections - updated WG e-mail list - indicate in abstract that the MIB is specific to IPv4 - changed references from "hitless" restart to "graceful" restart - added section 1.5 describing reference for implementing MIB views on multiple OSPF instances - new page number format in footer Piotr and Dan _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 30 06:47:40 2003 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 GAA18610 for ; Thu, 30 Oct 2003 06:47:40 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C2CFD0@cherry.ease.lsoft.com>; Thu, 30 Oct 2003 6:47:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59207234 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Oct 2003 06:47:47 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Oct 2003 06:47:46 -0400 Received: from kailash1.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 30 Oct 2003 17:08:15 +0530 Received: from subratm (subratm.future.futsoft.com [10.36.11.9]) by kailash1.future.futsoft.com (8.11.0/8.11.0) with SMTP id h9UBVtT11109 for ; Thu, 30 Oct 2003 17:01:55 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <000001c39ed9$48df6e40$090b240a@future.futsoft.com> Date: Thu, 30 Oct 2003 17:00:55 +0530 Reply-To: Mailing List Sender: Mailing List From: Subratm Subject: Regarding functionally equivalent LSA. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031029185955.826CC1E4A3@xmxpita.excite.com> Precedence: list Content-Transfer-Encoding: 7bit Pl. look at the following scenario. 10.0.0.0 20.0.0.0 30.0.0.0 R1------------R2-------------R3---------- R1,R2 are ASBRs. Router id of R1 is 10.0.0.4 Router id of R2 is 10.0.0.3 Router id of R2 is 30.0.0.3 R1 and R2 have static route to the network 11.0.0.0/8. So both R1 and R2 originate ASExt LSA for the network 11.0.0.0/8. Because R1 has the higher router id, R2 flushes out the ASExt LSA for the network 11.0.0.0/8 originated by itself. Now all three routers (R1,R2,R3) have the ASExt LSA for the network 11.0.0.0/8 originated by R1. Therefore they have the route to 11.0.0.0/8 in the ip routing table. Now R1 goes down. R2 and R3 delete the route to 11.0.0.0/8 from the ip routing table. But R2 is not able to originate the ASExt LSA as the existing ASExtLSA for 11.0.0.0/8 has the higher router id (R1's router id). So R3 does not have the route to 11.0.0.0/8. R2 and R3 has the ASExt LSA for 11.0.0.0/8 originated by R1. Ideally how should R2 behave so that R3 will have the route to 11.0.0.0/8 in it's IP routing table. Regards Subrat *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 30 07:19:06 2003 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 HAA19483 for ; Thu, 30 Oct 2003 07:19:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C2D031@cherry.ease.lsoft.com>; Thu, 30 Oct 2003 7:19:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59208728 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Oct 2003 07:19:12 -0500 Received: from 203.199.83.248 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Oct 2003 07:19:12 -0400 Received: (qmail 4300 invoked by uid 510); 30 Oct 2003 12:18:07 -0000 Received: from unknown (128.107.253.39) by rediffmail.com via HTTP; 30 oct 2003 12:18:07 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1067516287---0-203.199.83.248-4283" Message-ID: <20031030121807.4299.qmail@webmail36.rediffmail.com> Date: Thu, 30 Oct 2003 12:18:07 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Regarding functionally equivalent LSA. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1067516287---0-203.199.83.248-4283 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A1) R1 goes down
=0A2) R2 looses the ASBR entry to R1
=0A3) R1 r= eoriginates static routes flushed previously because of same
=0A  = being originated by R1.
=0A  Morever R1 should only flush As Ext L= SA (being of lower router id)
=0A  only if ASBR (of higher router= id) is reachable.
=0AHow is it done may vary with implementations.
= =0A
=0A-Vivek
=0A
=0A
=0A
=0A
=0AOn Thu, 30 Oct 2003 Subr= atm wrote :
=0A>Pl. look at the following scenario.
=0A>
=0A= >        10.0.0.0      20.0.0.0&nbs= p;     30.0.0.0
=0A>      R1------------R2--= -----------R3----------
=0A>
=0A>R1,R2 are ASBRs.
=0A>=0A>Router id of R1 is 10.0.0.4
=0A>Router id of R2 is 10.0.0.3=0A>Router id of R2 is 30.0.0.3
=0A>
=0A>R1 and R2 have st= atic route to the network 11.0.0.0/8. So both R1 and R2
=0A>originate= ASExt LSA for the network 11.0.0.0/8. Because R1 has the higher
=0A>= router id, R2 flushes out the ASExt LSA for the network 11.0.0.0/8
=0A&g= t;originated by itself. Now all three routers (R1,R2,R3) have the ASExt LSA=
=0A>for the network 11.0.0.0/8 originated by R1. Therefore they have= the route
=0A>to 11.0.0.0/8 in the ip routing table.
=0A>
= =0A>Now R1 goes down. R2 and R3 delete the route to 11.0.0.0/8 from the = ip
=0A>routing table. But R2  is not able to originate the ASExt= LSA as the
=0A>existing ASExtLSA for 11.0.0.0/8 has the higher route= r id (R1's router id).
=0A>So R3 does not have the route to 11.0.0.0/= 8. R2 and R3 has the ASExt LSA for
=0A>11.0.0.0/8 originated by R1.=0A>
=0A>Ideally how should R2 behave so that R3 will have the r= oute to 11.0.0.0/8 in
=0A>it's IP routing table.
=0A>
=0A>= ;Regards Subrat
=0A>
=0A>
=0A>
=0A>****************= ***********************************************************
=0A>This = message is proprietary to Future Software Limited (FSL)
=0A>and is in= tended solely for the use of the individual to whom it
=0A>is address= ed. It may contain  privileged or confidential information
=0A>a= nd should not be circulated or used for any purpose other than for
=0A&g= t;what it is intended.
=0A>
=0A>If you have received this messa= ge in error, please notify the
=0A>originator immediately. If you are= not the intended recipient,
=0A>you are notified that you are strict= ly prohibited from using,
=0A>copying, altering, or disclosing the co= ntents of this message.
=0A>FSL accepts no responsibility for loss or= damage arising from
=0A>the use of the information transmitted by th= is email including
=0A>damage from virus.
=0A>*****************= **********************************************************
=0A=0A

=0A=

=0A=0A --Next_1067516287---0-203.199.83.248-4283 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 1) R1 goes down=0A2) R2 looses the ASBR entry to R1=0A3) R1 reoriginates st= atic routes flushed previously because of same=0A being originated by R1.= =0A Morever R1 should only flush As Ext LSA (being of lower router id) = =0A only if ASBR (of higher router id) is reachable.=0AHow is it done may= vary with implementations.=0A=0A-Vivek=0A=0A=0A=0A=0AOn Thu, 30 Oct 2003 S= ubratm wrote :=0A>Pl. look at the following scenario.=0A>=0A> 10.0.= 0.0 20.0.0.0 30.0.0.0=0A> R1------------R2-------------R3--= --------=0A>=0A>R1,R2 are ASBRs.=0A>=0A>Router id of R1 is 10.0.0.4=0A>Rout= er id of R2 is 10.0.0.3=0A>Router id of R2 is 30.0.0.3=0A>=0A>R1 and R2 hav= e static route to the network 11.0.0.0/8. So both R1 and R2=0A>originate AS= Ext LSA for the network 11.0.0.0/8. Because R1 has the higher=0A>router id,= R2 flushes out the ASExt LSA for the network 11.0.0.0/8=0A>originated by i= tself. Now all three routers (R1,R2,R3) have the ASExt LSA=0A>for the netwo= rk 11.0.0.0/8 originated by R1. Therefore they have the route=0A>to 11.0.0.= 0/8 in the ip routing table.=0A>=0A>Now R1 goes down. R2 and R3 delete the = route to 11.0.0.0/8 from the ip=0A>routing table. But R2 is not able to or= iginate the ASExt LSA as the=0A>existing ASExtLSA for 11.0.0.0/8 has the hi= gher router id (R1's router id).=0A>So R3 does not have the route to 11.0.0= .0/8. R2 and R3 has the ASExt LSA for=0A>11.0.0.0/8 originated by R1.=0A>= =0A>Ideally how should R2 behave so that R3 will have the route to 11.0.0.0= /8 in=0A>it's IP routing table.=0A>=0A>Regards Subrat=0A>=0A>=0A>=0A>******= *********************************************************************=0A>Th= is message is proprietary to Future Software Limited (FSL)=0A>and is intend= ed solely for the use of the individual to whom it=0A>is addressed. It may = contain privileged or confidential information=0A>and should not be circul= ated or used for any purpose other than for=0A>what it is intended.=0A>=0A>= If you have received this message in error, please notify the=0A>originator= immediately. If you are not the intended recipient,=0A>you are notified th= at you are strictly prohibited from using,=0A>copying, altering, or disclos= ing the contents of this message.=0A>FSL accepts no responsibility for loss= or damage arising from=0A>the use of the information transmitted by this e= mail including=0A>damage from virus.=0A>***********************************= ****************************************=0A --Next_1067516287---0-203.199.83.248-4283-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 30 07:43:48 2003 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 HAA20094 for ; Thu, 30 Oct 2003 07:43:47 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C2D08B@cherry.ease.lsoft.com>; Thu, 30 Oct 2003 7:43:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59209538 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Oct 2003 07:43:51 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Oct 2003 07:43:50 -0400 Received: from kailash1.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 30 Oct 2003 17:56:38 +0530 Received: from lakshmips (lakshmips.future.futsoft.com [10.4.4.23]) by kailash1.future.futsoft.com (8.11.0/8.11.0) with SMTP id h9UCKGT14750 for ; Thu, 30 Oct 2003 17:50:16 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Message-ID: <002701c39ede$41994d40$1704040a@future.futsoft.com> Date: Thu, 30 Oct 2003 17:36:30 +0530 Reply-To: Mailing List Sender: Mailing List From: Lakshmips Subject: Re: Regarding functionally equivalent LSA. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c39ed9$48df6e40$090b240a@future.futsoft.com> Precedence: list Content-Transfer-Encoding: 7bit In my opinion, functionally equivalent lsas handling by a router (R2) should consider the following scenarios: 1. check whether it needs to originate an external lsa (if functionally equivalent lsa already exist,based on router id) 2. check whether it has to purge its own lsa when a functionally equivalent one is originated by a different router of higher router id 3. Also be able to decide and originate a functinally equivalent lsa when one from a neighbor is deleted. your problem lies in point 3. At any instance the implementation should take care such that, R2 is able to originate an ext lsa (considering if any other functionally equivalent lsa of higher router id exists), once it deletes the type 5 lsa of R1. Lakshmi Priya.S -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Subratm Sent: Thursday, 30 October 2003 5:01 PM To: OSPF@peach.ease.lsoft.com Subject: Regarding functionally equivalent LSA. Pl. look at the following scenario. 10.0.0.0 20.0.0.0 30.0.0.0 R1------------R2-------------R3---------- R1,R2 are ASBRs. Router id of R1 is 10.0.0.4 Router id of R2 is 10.0.0.3 Router id of R2 is 30.0.0.3 R1 and R2 have static route to the network 11.0.0.0/8. So both R1 and R2 originate ASExt LSA for the network 11.0.0.0/8. Because R1 has the higher router id, R2 flushes out the ASExt LSA for the network 11.0.0.0/8 originated by itself. Now all three routers (R1,R2,R3) have the ASExt LSA for the network 11.0.0.0/8 originated by R1. Therefore they have the route to 11.0.0.0/8 in the ip routing table. Now R1 goes down. R2 and R3 delete the route to 11.0.0.0/8 from the ip routing table. But R2 is not able to originate the ASExt LSA as the existing ASExtLSA for 11.0.0.0/8 has the higher router id (R1's router id). So R3 does not have the route to 11.0.0.0/8. R2 and R3 has the ASExt LSA for 11.0.0.0/8 originated by R1. Ideally how should R2 behave so that R3 will have the route to 11.0.0.0/8 in it's IP routing table. Regards Subrat *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 30 08:15:44 2003 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 IAA21229 for ; Thu, 30 Oct 2003 08:15:44 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C2D14B@cherry.ease.lsoft.com>; Thu, 30 Oct 2003 8:15:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59210981 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Oct 2003 08:15:49 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Oct 2003 08:15:46 -0400 Received: from kailash1.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 30 Oct 2003 18:27:30 +0530 Received: from subratm (subratm.future.futsoft.com [10.36.11.9]) by kailash1.future.futsoft.com (8.11.0/8.11.0) with SMTP id h9UCp9T17335 for ; Thu, 30 Oct 2003 18:21:09 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C39F12.74604600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <000301c39ee4$5aa80a00$090b240a@future.futsoft.com> Date: Thu, 30 Oct 2003 18:20:09 +0530 Reply-To: Mailing List Sender: Mailing List From: Subratm Subject: Re: Regarding functionally equivalent LSA. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031030121807.4299.qmail@webmail36.rediffmail.com> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C39F12.74604600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In step 3 did u mean R1 to be R2 by mistake?? I am just modifying the sequence. Pl. let me know my understanding is correct. 1) R1 goes down 2) R2 looses the ASBR entry to R1 3) R2 reoriginates static routes flushed previously because of same being originated by R1. Morever R2 should only flush As Ext LSA (being of lower router id) only if ASBR (of higher router id) is reachable. How is it done may vary with implementations. -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Vivek Dubey Sent: Thursday, 30 October 2003 5:48 PM To: OSPF@peach.ease.lsoft.com Subject: Re: Regarding functionally equivalent LSA. 1) R1 goes down 2) R2 looses the ASBR entry to R1 3) R1 reoriginates static routes flushed previously because of same being originated by R1. Morever R1 should only flush As Ext LSA (being of lower router id) only if ASBR (of higher router id) is reachable. How is it done may vary with implementations. -Vivek On Thu, 30 Oct 2003 Subratm wrote : >Pl. look at the following scenario. > > 10.0.0.0 20.0.0.0 30.0.0.0 > R1------------R2-------------R3---------- > >R1,R2 are ASBRs. > >Router id of R1 is 10.0.0.4 >Router id of R2 is 10.0.0.3 >Router id of R2 is 30.0.0.3 > >R1 and R2 have static route to the network 11.0.0.0/8. So both R1 and R2 >originate ASExt LSA for the network 11.0.0.0/8. Because R1 has the higher >router id, R2 flushes out the ASExt LSA for the network 11.0.0.0/8 >originated by itself. Now all three routers (R1,R2,R3) have the ASExt LSA >for the network 11.0.0.0/8 originated by R1. Therefore they have the route >to 11.0.0.0/8 in the ip routing table. > >Now R1 goes down. R2 and R3 delete the route to 11.0.0.0/8 from the ip >routing table. But R2 is not able to originate the ASExt LSA as the >existing ASExtLSA for 11.0.0.0/8 has the higher router id (R1's router id). >So R3 does not have the route to 11.0.0.0/8. R2 and R3 has the ASExt LSA for >11.0.0.0/8 originated by R1. > >Ideally how should R2 behave so that R3 will have the route to 11.0.0.0/8 in >it's IP routing table. > >Regards Subrat > > > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0004_01C39F12.74604600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In=20 step 3 did u mean R1 to be R2 by mistake?? I am just modifying the sequence= . Pl.=20 let me know my understanding is correct.
 
1) R1=20 goes down
2) R2 looses the ASBR entry to R1
3) R2 reoriginates static= routes flushed previously because of same
  being originated by=20 R1.
  Morever R2 should only flush As Ext LSA (being of lower route= r id)=20
  only if ASBR (of higher router id) is reachable.
How is it do= ne=20 may vary with implementations.
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Vivek=20 Dubey
Sent: Thursday, 30 October 2003 5:48 PM
To:=20 OSPF@peach.ease.lsoft.com
Subject: Re: Regarding functionally= equivalent LSA.

1) R1 goes down
2) R2 looses the ASBR entry to R1
3) R1 reorigin= ates=20 static routes flushed previously because of same
  being originat= ed by=20 R1.
  Morever R1 should only flush As Ext LSA (being of lower rou= ter=20 id)
  only if ASBR (of higher router id) is reachable.
How is= it=20 done may vary with implementations.

-Vivek




On T= hu,=20 30 Oct 2003 Subratm wrote :
>Pl. look at the following=20 scenario.
>
>        10.0.0.0   = ;=20   20.0.0.0      30.0.0.0
>     = R1------------R2-------------R3----------
>
>R1,R2 are=20 ASBRs.
>
>Router id of R1 is 10.0.0.4
>Router id of R2 = is=20 10.0.0.3
>Router id of R2 is 30.0.0.3
>
>R1 and R2 have= static route to the network 11.0.0.0/8. So both R1 and R2
>origina= te=20 ASExt LSA for the network 11.0.0.0/8. Because R1 has the higher
>ro= uter=20 id, R2 flushes out the ASExt LSA for the network 11.0.0.0/8
>origin= ated=20 by itself. Now all three routers (R1,R2,R3) have the ASExt LSA
>for= the=20 network 11.0.0.0/8 originated by R1. Therefore they have the route
>= ;to=20 11.0.0.0/8 in the ip routing table.
>
>Now R1 goes down. R2 a= nd R3=20 delete the route to 11.0.0.0/8 from the ip
>routing table. But R2&n= bsp;=20 is not able to originate the ASExt LSA as the
>existing ASExtLSA fo= r=20 11.0.0.0/8 has the higher router id (R1's router id).
>So R3 does n= ot=20 have the route to 11.0.0.0/8. R2 and R3 has the ASExt LSA=20 for
>11.0.0.0/8 originated by R1.
>
>Ideally how should= R2=20 behave so that R3 will have the route to 11.0.0.0/8 in
>it's IP rou= ting=20 table.
>
>Regards=20 Subrat
>
>
>
>***********************************= ****************************************
>This=20 message is proprietary to Future Software Limited (FSL)
>and is int= ended=20 solely for the use of the individual to whom it
>is addressed. It m= ay=20 contain  privileged or confidential information
>and should no= t be=20 circulated or used for any purpose other than for
>what it is=20 intended.
>
>If you have received this message in error, plea= se=20 notify the
>originator immediately. If you are not the intended=20 recipient,
>you are notified that you are strictly prohibited from= using,
>copying, altering, or disclosing the contents of this=20 message.
>FSL accepts no responsibility for loss or damage arising= from
>the use of the information transmitted by this email=20 including
>damage from=20 virus.
>***********************************************************= ****************





***************************************************************************=
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************=
------=_NextPart_000_0004_01C39F12.74604600-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 30 13:09:06 2003 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 NAA03341 for ; Thu, 30 Oct 2003 13:09:05 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C2D82D@cherry.ease.lsoft.com>; Thu, 30 Oct 2003 13:09:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58839070 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Oct 2003 13:09:10 -0500 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Oct 2003 13:09:10 -0400 Received: from user-38ldtpl.dialup.mindspring.com ([209.86.247.53] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AFHEL-0007mi-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Oct 2003 10:09:10 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <000301c39ee4$5aa80a00$090b240a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3FA1539E.B41913BF@earthlink.net> Date: Thu, 30 Oct 2003 10:08:30 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Regarding functionally equivalent LSA. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit To posters of this mail-thread, You do realize that this is a public mail alias and that no stated or inferred confidential information agreements are in place between members of this mail alias. Mitchell Erblich -------------------------- > Subratm wrote: > > In step 3 did u mean R1 to be R2 by mistake?? I am just modifying the > sequence. Pl. let me know my understanding is correct. > > 1) R1 goes down > 2) R2 looses the ASBR entry to R1 > 3) R2 reoriginates static routes flushed previously because of same > being originated by R1. > Morever R2 should only flush As Ext LSA (being of lower router id) > only if ASBR (of higher router id) is reachable. > How is it done may vary with implementations. > > -----Original Message----- > From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On > Behalf Of Vivek Dubey > Sent: Thursday, 30 October 2003 5:48 PM > To: OSPF@peach.ease.lsoft.com > Subject: Re: Regarding functionally equivalent LSA. > > 1) R1 goes down > 2) R2 looses the ASBR entry to R1 > 3) R1 reoriginates static routes flushed previously because > of same > being originated by R1. > Morever R1 should only flush As Ext LSA (being of lower > router id) > only if ASBR (of higher router id) is reachable. > How is it done may vary with implementations. > > -Vivek > > On Thu, 30 Oct 2003 Subratm wrote : > >Pl. look at the following scenario. > > > > 10.0.0.0 20.0.0.0 30.0.0.0 > > R1------------R2-------------R3---------- > > > >R1,R2 are ASBRs. > > > >Router id of R1 is 10.0.0.4 > >Router id of R2 is 10.0.0.3 > >Router id of R2 is 30.0.0.3 > > > >R1 and R2 have static route to the network 11.0.0.0/8. So > both R1 and R2 > >originate ASExt LSA for the network 11.0.0.0/8. Because R1 > has the higher > >router id, R2 flushes out the ASExt LSA for the network > 11.0.0.0/8 > >originated by itself. Now all three routers (R1,R2,R3) have > the ASExt LSA > >for the network 11.0.0.0/8 originated by R1. Therefore they > have the route > >to 11.0.0.0/8 in the ip routing table. > > > >Now R1 goes down. R2 and R3 delete the route to 11.0.0.0/8 > from the ip > >routing table. But R2 is not able to originate the ASExt > LSA as the > >existing ASExtLSA for 11.0.0.0/8 has the higher router id > (R1's router id). > >So R3 does not have the route to 11.0.0.0/8. R2 and R3 has > the ASExt LSA for > >11.0.0.0/8 originated by R1. > > > >Ideally how should R2 behave so that R3 will have the route > to 11.0.0.0/8 in > >it's IP routing table. > > > >Regards Subrat > > > > > > > >*************************************************************************** > >This message is proprietary to Future Software Limited > (FSL) > >and is intended solely for the use of the individual to > whom it > >is addressed. It may contain privileged or confidential > information > >and should not be circulated or used for any purpose other > than for > >what it is intended. > > > >If you have received this message in error, please notify > the > >originator immediately. If you are not the intended > recipient, > >you are notified that you are strictly prohibited from > using, > >copying, altering, or disclosing the contents of this > message. > >FSL accepts no responsibility for loss or damage arising > from > >the use of the information transmitted by this email > including > >damage from virus. > >*************************************************************************** > > [Image] > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 30 16:22:47 2003 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 QAA12227 for ; Thu, 30 Oct 2003 16:22:47 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C2DE5B@cherry.ease.lsoft.com>; Thu, 30 Oct 2003 16:22:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58866310 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Oct 2003 16:22:51 -0500 Received: from 195.207.101.250 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Oct 2003 16:22:51 -0400 Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id h9UJPvr2012458 for ; Thu, 30 Oct 2003 20:25:57 +0100 Received: from alcatel.be ([138.203.67.234]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003103022224998:4600 ; Thu, 30 Oct 2003 22:22:49 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F996B61.8040606@redback.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/30/2003 22:22:50, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/30/2003 22:22:51, Serialize complete at 10/30/2003 22:22:51 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.37 Message-ID: <3FA18198.8030600@alcatel.be> Date: Thu, 30 Oct 2003 22:24:40 +0100 Reply-To: Mailing List Sender: Mailing List From: Dimitri.Papadimitriou@ALCATEL.BE Subject: Re: I-D ACTION:draft-ietf-ospf-cap-01.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F996B61.8040606@redback.com> Precedence: list Content-Transfer-Encoding: 7bit hi acee, what's however difficult to understand in this i-d, is the difference between "ospf capabilities for mpls-te" and "advertise mpls-te capabilities" this ambiguity is imho translated in the following flag: 9 OSPF Path Computation Server discovery [7, 8] where [7] stands for OSPF PCS discovery and [8] which refers to the query/response RSVP-TE capability i don't know if there is a possibility to translate this in a more structured way ? this imho can only be responsed if a clear definition of what "mpls-te capability" is provided, in particular concerning the following: "or the intention of an LSR to be part of a particular MPLS TE mesh group." i'm not sure if this is a real mpls-te capability or more like an mpls-te local policy configuration ? thanks, - dimitri. Acee Lindem wrote: > Dan Dovolsky wrote: > >> I have couple questions to authors of this draft. >> >> 1. Could you, please, enumerate reasons why you want to have Router >> Options >> advertisements in the new separated Opaque LSA? >> Why the TE Router Opaque LSA is not good for it? RFC3630 doesn't prevent >> adding of new tlvs into it. >> > This is a more generalized mechanism. I'm sure what it is used for will > be a topic for debate. > >> >> 2. Is it possible scenario when you don't have TE Router Opaque LSA >> but you >> do have the new RI Opaque LSA? >> > > Yes. > >> >> Thanks, >> Dan Dovolsky >> >> >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of >> Internet-Drafts@IETF.ORG >> Sent: Friday, October 24, 2003 10:51 AM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: I-D ACTION:draft-ietf-ospf-cap-01.txt >> >> >> 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, N. Shen, R. Aggarwal, S. Shaffer, J. >> Vasseur >> Filename : draft-ietf-ospf-cap-01.txt >> Pages : 8 >> Date : 2003-10-23 >> >> It is useful for routers in an OSPF routing domain to know the >> capabilities >> of their neighbors and other routers in the OSPF routing domain. This >> draft >> proposes extensions to OSPF for advertising optional router >> capabilities. A >> new Router Information (RI) opaque LSA is proposed for this purpose. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-01.txt >> >> To remove yourself from the IETF Announcement list, send a message to >> ietf-announce-request with the word unsubscribe in the body of the >> message. >> >> 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-01.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-ospf-cap-01.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 30 23:13:14 2003 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 XAA27863 for ; Thu, 30 Oct 2003 23:13:14 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C2E85B@cherry.ease.lsoft.com>; Thu, 30 Oct 2003 23:13:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58885893 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Oct 2003 23:11:07 -0500 Received: from 64.4.15.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Oct 2003 23:01:07 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 30 Oct 2003 20:01:07 -0800 Received: from 64.230.26.171 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 31 Oct 2003 04:01:06 GMT X-Originating-IP: [64.230.26.171] X-Originating-Email: [sarahsmith_510@hotmail.com] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 31 Oct 2003 04:01:07.0169 (UTC) FILETIME=[9C704D10:01C39F63] Message-ID: Date: Fri, 31 Oct 2003 04:01:06 +0000 Reply-To: Mailing List Sender: Mailing List From: sarah smith Subject: TED To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I have two questions about the TED. Thanks to Acee and Kireeti for answering me other questions! 1. Both TE LSA and network LSA are used in TE calculation. - how would we use the network LSA for TE calculation? How is this stored in TED. Is it only used for multi-access links ? 2. When we build TED, do we need to keep track of a link which is an ISIS or OSPF or both? Thanks, Sarah. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 31 13:53:08 2003 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 NAA13028 for ; Fri, 31 Oct 2003 13:53:08 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C2F9FD@cherry.ease.lsoft.com>; Fri, 31 Oct 2003 13:53:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58974836 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 31 Oct 2003 13:53:14 -0500 Received: from 62.241.160.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Oct 2003 13:53:14 -0400 Received: from tom3 (1Cust239.tnt15.lnd4.gbr.da.uu.net [62.188.144.239]) by colossus.systems.pipex.net (Postfix) with SMTP id 95E9C160000EF for ; Fri, 31 Oct 2003 18:53:12 +0000 (GMT) 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <006001c39fdf$ce4ecce0$0301a8c0@tom3> Date: Fri, 31 Oct 2003 11:59:50 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Regarding functionally equivalent LSA. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit And do you realise that while the messages contain disclaimers that they are not responsible for any damage done by virus, yet they contain HTML that demands to be connected when the message is opened, ie opening up my system to virus attack? (sent as text/plain) Tom Petch -----Original Message----- From: Erblichs To: OSPF@PEACH.EASE.LSOFT.COM Date: 30 October 2003 18:09 Subject: Re: Regarding functionally equivalent LSA. >To posters of this mail-thread, > > You do realize that this is a public mail alias and > that no stated or inferred confidential information > agreements are in place between members of this mail > alias. > > Mitchell Erblich > -------------------------- > >> Subratm wrote: >> >> In step 3 did u mean R1 to be R2 by mistake?? I am just modifying the >> sequence. Pl. let me know my understanding is correct. >> >> 1) R1 goes down >> 2) R2 looses the ASBR entry to R1 >> 3) R2 reoriginates static routes flushed previously because of same >> being originated by R1. >> Morever R2 should only flush As Ext LSA (being of lower router id) >> only if ASBR (of higher router id) is reachable. >> How is it done may vary with implementations. >> >> -----Original Message----- >> From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On >> Behalf Of Vivek Dubey >> Sent: Thursday, 30 October 2003 5:48 PM >> To: OSPF@peach.ease.lsoft.com >> Subject: Re: Regarding functionally equivalent LSA. >> >> 1) R1 goes down >> 2) R2 looses the ASBR entry to R1 >> 3) R1 reoriginates static routes flushed previously because >> of same >> being originated by R1. >> Morever R1 should only flush As Ext LSA (being of lower >> router id) >> only if ASBR (of higher router id) is reachable. >> How is it done may vary with implementations. >> >> -Vivek >> >> On Thu, 30 Oct 2003 Subratm wrote : >> >Pl. look at the following scenario. >> > >> > 10.0.0.0 20.0.0.0 30.0.0.0 >> > R1------------R2-------------R3---------- >> > >> >R1,R2 are ASBRs. >> > >> >Router id of R1 is 10.0.0.4 >> >Router id of R2 is 10.0.0.3 >> >Router id of R2 is 30.0.0.3 >> > >> >R1 and R2 have static route to the network 11.0.0.0/8. So >> both R1 and R2 >> >originate ASExt LSA for the network 11.0.0.0/8. Because R1 >> has the higher >> >router id, R2 flushes out the ASExt LSA for the network >> 11.0.0.0/8 >> >originated by itself. Now all three routers (R1,R2,R3) have >> the ASExt LSA >> >for the network 11.0.0.0/8 originated by R1. Therefore they >> have the route >> >to 11.0.0.0/8 in the ip routing table. >> > >> >Now R1 goes down. R2 and R3 delete the route to 11.0.0.0/8 >> from the ip >> >routing table. But R2 is not able to originate the ASExt >> LSA as the >> >existing ASExtLSA for 11.0.0.0/8 has the higher router id >> (R1's router id). >> >So R3 does not have the route to 11.0.0.0/8. R2 and R3 has >> the ASExt LSA for >> >11.0.0.0/8 originated by R1. >> > >> >Ideally how should R2 behave so that R3 will have the route >> to 11.0.0.0/8 in >> >it's IP routing table. >> > >> >Regards Subrat >> > >> > >> > >> >*************************************************************************** >> >This message is proprietary to Future Software Limited >> (FSL) >> >and is intended solely for the use of the individual to >> whom it >> >is addressed. It may contain privileged or confidential >> information >> >and should not be circulated or used for any purpose other >> than for >> >what it is intended. >> > >> >If you have received this message in error, please notify >> the >> >originator immediately. If you are not the intended >> recipient, >> >you are notified that you are strictly prohibited from >> using, >> >copying, altering, or disclosing the contents of this >> message. >> >FSL accepts no responsibility for loss or damage arising >> from >> >the use of the information transmitted by this email >> including >> >damage from virus. >> >*************************************************************************** >> >> [Image] >> >> *************************************************************************** >> This message is proprietary to Future Software Limited (FSL) >> and is intended solely for the use of the individual to whom it >> is addressed. It may contain privileged or confidential information >> and should not be circulated or used for any purpose other than for >> what it is intended. >> >> If you have received this message in error, please notify the >> originator immediately. If you are not the intended recipient, >> you are notified that you are strictly prohibited from using, >> copying, altering, or disclosing the contents of this message. >> FSL accepts no responsibility for loss or damage arising from >> the use of the information transmitted by this email including >> damage from virus. >> *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 31 14:15:59 2003 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 OAA14263 for ; Fri, 31 Oct 2003 14:15:59 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C2F972@cherry.ease.lsoft.com>; Fri, 31 Oct 2003 14:16:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58976658 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 31 Oct 2003 14:16:07 -0500 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Oct 2003 14:16:07 -0400 Received: from user-38ldvlh.dialup.mindspring.com ([209.86.254.177] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AFekX-0007ON-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 31 Oct 2003 11:15:58 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <006001c39fdf$ce4ecce0$0301a8c0@tom3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3FA2B3EA.22D803B9@earthlink.net> Date: Fri, 31 Oct 2003 11:11:38 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Regarding functionally equivalent LSA. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom, I was just giving them notice that what they sent out was no longer "confidential", if it was in the past. Simply, Because they made it public. Mitchell Erblich *************************************************************************** >> This message is proprietary to Future Software Limited (FSL) >> and is intended solely for the use of the individual to whom it >> is addressed. It may contain privileged or confidential information >> and should not be circulated or used for any purpose other than for >> what it is intended. ............ Tom Petch wrote: > > And do you realise that while the messages contain disclaimers that they are not > responsible for any damage done by virus, yet they contain HTML that demands to > be connected when the message is opened, ie opening up my system to virus > attack? > > (sent as text/plain) > > Tom Petch > > -----Original Message----- > From: Erblichs > To: OSPF@PEACH.EASE.LSOFT.COM > Date: 30 October 2003 18:09 > Subject: Re: Regarding functionally equivalent LSA. > > >To posters of this mail-thread, > > > > You do realize that this is a public mail alias and > > that no stated or inferred confidential information > > agreements are in place between members of this mail > > alias. > > > > Mitchell Erblich > > -------------------------- > > > >> Subratm wrote: > >> > >> In step 3 did u mean R1 to be R2 by mistake?? I am just modifying the > >> sequence. Pl. let me know my understanding is correct. > >> > >> 1) R1 goes down > >> 2) R2 looses the ASBR entry to R1 > >> 3) R2 reoriginates static routes flushed previously because of same > >> being originated by R1. > >> Morever R2 should only flush As Ext LSA (being of lower router id) > >> only if ASBR (of higher router id) is reachable. > >> How is it done may vary with implementations. > >> > >> -----Original Message----- > >> From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On > >> Behalf Of Vivek Dubey > >> Sent: Thursday, 30 October 2003 5:48 PM > >> To: OSPF@peach.ease.lsoft.com > >> Subject: Re: Regarding functionally equivalent LSA. > >> > >> 1) R1 goes down > >> 2) R2 looses the ASBR entry to R1 > >> 3) R1 reoriginates static routes flushed previously because > >> of same > >> being originated by R1. > >> Morever R1 should only flush As Ext LSA (being of lower > >> router id) > >> only if ASBR (of higher router id) is reachable. > >> How is it done may vary with implementations. > >> > >> -Vivek > >> > >> On Thu, 30 Oct 2003 Subratm wrote : > >> >Pl. look at the following scenario. > >> > > >> > 10.0.0.0 20.0.0.0 30.0.0.0 > >> > R1------------R2-------------R3---------- > >> > > >> >R1,R2 are ASBRs. > >> > > >> >Router id of R1 is 10.0.0.4 > >> >Router id of R2 is 10.0.0.3 > >> >Router id of R2 is 30.0.0.3 > >> > > >> >R1 and R2 have static route to the network 11.0.0.0/8. So > >> both R1 and R2 > >> >originate ASExt LSA for the network 11.0.0.0/8. Because R1 > >> has the higher > >> >router id, R2 flushes out the ASExt LSA for the network > >> 11.0.0.0/8 > >> >originated by itself. Now all three routers (R1,R2,R3) have > >> the ASExt LSA > >> >for the network 11.0.0.0/8 originated by R1. Therefore they > >> have the route > >> >to 11.0.0.0/8 in the ip routing table. > >> > > >> >Now R1 goes down. R2 and R3 delete the route to 11.0.0.0/8 > >> from the ip > >> >routing table. But R2 is not able to originate the ASExt > >> LSA as the > >> >existing ASExtLSA for 11.0.0.0/8 has the higher router id > >> (R1's router id). > >> >So R3 does not have the route to 11.0.0.0/8. R2 and R3 has > >> the ASExt LSA for > >> >11.0.0.0/8 originated by R1. > >> > > >> >Ideally how should R2 behave so that R3 will have the route > >> to 11.0.0.0/8 in > >> >it's IP routing table. > >> > > >> >Regards Subrat > >> > > >> > > >> > > >> > >*************************************************************************** > >> >This message is proprietary to Future Software Limited > >> (FSL) > >> >and is intended solely for the use of the individual to > >> whom it > >> >is addressed. It may contain privileged or confidential > >> information > >> >and should not be circulated or used for any purpose other > >> than for > >> >what it is intended. > >> > > >> >If you have received this message in error, please notify > >> the > >> >originator immediately. If you are not the intended > >> recipient, > >> >you are notified that you are strictly prohibited from > >> using, > >> >copying, altering, or disclosing the contents of this > >> message. > >> >FSL accepts no responsibility for loss or damage arising > >> from > >> >the use of the information transmitted by this email > >> including > >> >damage from virus. > >> > >*************************************************************************** > >> > >> [Image] > >> > >> *************************************************************************** > >> This message is proprietary to Future Software Limited (FSL) > >> and is intended solely for the use of the individual to whom it > >> is addressed. It may contain privileged or confidential information > >> and should not be circulated or used for any purpose other than for > >> what it is intended. > >> > >> If you have received this message in error, please notify the > >> originator immediately. If you are not the intended recipient, > >> you are notified that you are strictly prohibited from using, > >> copying, altering, or disclosing the contents of this message. > >> FSL accepts no responsibility for loss or damage arising from > >> the use of the information transmitted by this email including > >> damage from virus. > >> ***************************************************************************