From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 9 10:42:15 2004 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 KAA07017 for ; Fri, 9 Jan 2004 10:42: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 <5.00C96127@cherry.ease.lsoft.com>; Tue, 6 Jan 2004 11:46:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 66920630 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jan 2004 11:46:01 -0500 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jan 2004 11:46:01 -0500 Received: from user-38lc0fl.dialup.mindspring.com ([209.86.1.245] helo=erg.sri.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AduL9-0007WD-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 06 Jan 2004 08:46:00 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <3FDF3DF9.1070609@erg.sri.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FFAE640.3080006@erg.sri.com> Date: Tue, 6 Jan 2004 08:45:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Below, I am reposting a message to Tom Henderson that I previously posted on the MANET list on Dec 22, in an effort to continue this discussion on the OSPF list. (I previously posted a link to this message, but the link is not permanent and thus would not result in the message being properly archived.) Tom, Please see my comments below. >>We can start this discussion now. If you want to achieve periodic >>unreliable flooding of LSAs, all you have to do is suppress LSA ACKs, >>as discussed in Section 5 of draft-ogier-manet-ospf-extension-00.txt. >>Moreover, a router can dynamically *decide* whether to suppress >>ACKs for a particular LSA, depending on how frequently it receives >>a new instance of the LSA (with a larger sequence number). >>(This approach can be used with a CDS or with MPRs.) >>I would be interested if you (or anyone) can give a good reason >>why this is not a good approach. >Richard, >I like this basic concept of yours because it offers the potential >for hybrid operation without much complexity in the protocol >mechanism. It also appears fairly robust to the case where >routers are making inconsistent decisions on whether to suppress >ACKs-- retransmissions just keep occuring until the stingiest >neighbor decides to ACK. If we could allow nodes to suppress >ACKs for a short time, it would allow them to logically coalesce >ACKs of the same LSA received from many neighbors into a single Right. OSPF allows LSA ACKs to be delayed, and the technique of grouping several LSA ACKs into a single packet is mentioned in Section 13.5 of RFC 2328, so this would not require an extension to the standard, but perhaps a recommendation should be added that this technique SHOULD be used on manet interfaces. >transmission. Further, it could perhaps be extended as Fred >Baker has previously suggested that reflooding of an LSA can >serve also as an implicit ACK to the upstream neighbor. The RFC 2328 also allows implicit ACKs, so this also would not require an extension. But there is still the question of whether implicit ACKs should be used on manet interfaces. It probably wouldn't hurt, but it wouldn't help much either, since only a small percentage of nodes will forward LSAs (e.g., CDS nodes or MPRs). >main implementation cost seems to be to maintain and update >the moving average for each LSA. I think this cost is negligible, since each LSA must be processed anyway (and updating a moving average requires only a few additions and multiplications). It would be interesting to determine the best values for the smoothing constant, hysteresis thresholds (for deciding whether to suppress ACKs), and the ACK delay when ACKs are not suppressed. >>Actually, I think the reliable flooding mechanism described in >>Section 6 of my draft is a better (more efficient) approach, >>but it requires more changes to OSPF, and therefore might not >>be as acceptable to the OSPF WG. >Agreed. It would be interesting to see how far one could get >by adopting the Section 5 approach by itself. I agree. But if reliable flooding is used, there still needs to be a database exchange between adjacent neighbors. As discussed in my draft this exchange could occur between each CDS node and each of its neighbors. I suppose this could also be done between each MPR and each of its neighbors, but this is not as straightforward since each MPR is reponsible for relaying only a subset of LSAs (which must somehow be defined). So, to minimize the changes/additions to OSPF, the CDS approach seems to be the best approach. Richard > >Tom > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 9 10:42:17 2004 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 KAA07028 for ; Fri, 9 Jan 2004 10:42:16 -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 <11.00C993E2@cherry.ease.lsoft.com>; Thu, 8 Jan 2004 0:17:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67136020 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jan 2004 00:17:06 -0500 Received: from 202.249.37.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jan 2004 00:07:00 -0500 Received: from [202.249.37.12] (sec01.koganei.wide.ad.jp [202.249.37.12]) by ns.koganei.wide.ad.jp (8.12.9/8.12.6) with ESMTP id i0856wke004307 for ; Thu, 8 Jan 2004 14:06:58 +0900 (JST) (envelope-from zhang@koganei.wide.ad.jp) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 Message-ID: <20040108134641.08B6.ZHANG@koganei.wide.ad.jp> Date: Thu, 8 Jan 2004 14:06:36 +0900 Reply-To: Mailing List Sender: Mailing List From: Zhang Shu Subject: field length in ospfv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi there, Can anyone please tell me what the length of following fields is in RFC2740? It is difficult to determine them from the packet format in the RFC and there seems not to be any description of them (I apology if I missed them). 1. Section A.4.4 Network-LSAs "0", Options field (right after the LSA header) 2. Section A.4.5 Inter-Area-Prefix-LSAs "0", Metric field (right after the LSA header) 3. Section A.4.6 Inter-Area-Router-LSAs "0" ,Options field (right after the LSA header) and the following "0", Metric field Thanks in advance! Zhang Shu From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 9 10:42:17 2004 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 KAA07053 for ; Fri, 9 Jan 2004 10:42: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 <7.00C995DF@cherry.ease.lsoft.com>; Thu, 8 Jan 2004 0:44:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67146232 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jan 2004 00:44:06 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jan 2004 00:44:05 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 8 Jan 2004 11:20:11 +0530 Received: from lakshmips (lakshmips.future.futsoft.com [10.8.3.71]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i085cWU09441 for ; Thu, 8 Jan 2004 11:08:32 +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: <002901c3d5a8$069d4ce0$4703080a@future.futsoft.com> Date: Thu, 8 Jan 2004 10:56:52 +0530 Reply-To: Mailing List Sender: Mailing List From: Lakshmips Subject: Re: field length in ospfv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20040108134641.08B6.ZHANG@koganei.wide.ad.jp> Precedence: list Content-Transfer-Encoding: 7bit hi, Section A.2. rfc 2740 describes the option field. The option field in all the mentioned packets is 24-bits. The metric field is also 24-bits. The "0" occupies 8bits. regards lakshmi priya -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Zhang Shu Sent: Thursday, 8 January 2004 10:37 AM To: OSPF@peach.ease.lsoft.com Subject: field length in ospfv3 Hi there, Can anyone please tell me what the length of following fields is in RFC2740? It is difficult to determine them from the packet format in the RFC and there seems not to be any description of them (I apology if I missed them). 1. Section A.4.4 Network-LSAs "0", Options field (right after the LSA header) 2. Section A.4.5 Inter-Area-Prefix-LSAs "0", Metric field (right after the LSA header) 3. Section A.4.6 Inter-Area-Router-LSAs "0" ,Options field (right after the LSA header) and the following "0", Metric field Thanks in advance! Zhang Shu *************************************************************************** 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 Jan 9 10:42:18 2004 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 KAA07067 for ; Fri, 9 Jan 2004 10:42:18 -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 <15.00C99784@cherry.ease.lsoft.com>; Thu, 8 Jan 2004 3:00:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67153290 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jan 2004 03:00:23 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jan 2004 02:50:23 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C99627@cherry.ease.lsoft.com>; Thu, 8 Jan 2004 2:50:23 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jan 2004 02:50:22 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 8 Jan 2004 13:26:19 +0530 Received: from kishoreky (kishoreky.future.futsoft.com [10.6.4.95]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i087iXU17142 for ; Thu, 8 Jan 2004 13:14:34 +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 V6.00.2800.1106 Importance: Normal Message-ID: <001301c3d5bb$81e86e80$5f04060a@future.futsoft.com> Date: Thu, 8 Jan 2004 13:16:20 +0530 Reply-To: Mailing List Sender: Mailing List From: Kishore Kumar Y Subject: virtual link transit summary lsa Comments: To: Mailing List To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20020815.162132.64931757.yasu@sfc.wide.ad.jp> Precedence: list Content-Transfer-Encoding: 7bit backbone transit area 1 area 2 -----------R1-----------------R2----------------------R3------- 10.0.0.1 20.0.0.x 30.0.0.x 40.0.0.1 i configured a virtual link between router R2 and R3. the cost for each interface is 10. my doubt is at router R3 10.0.0.0 network route entry path type should be INTER AREA or INTRA AREA. according to RFC 2328 section 16.3 while doing Transit summary lsa calculation path type should remain same INTRA AREA or INTER AREA found during calculation 16.1 and 16.2 i feel path type should be INTRA AREA though the path is through transit area. ******************************************** Yarlagadda Kishore Kumar Future Software Ltd., 480-481, Mount Road, Nandanam, chennai 600 035 ph: 91-44-433 0550 Ex -305 (O) kishoreky@future.futsoft.com yarlagadda_kk@lycos.com ******************************************** *************************************************************************** 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 Jan 9 10:42:19 2004 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 KAA07074 for ; Fri, 9 Jan 2004 10:42:19 -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.00C99C38@cherry.ease.lsoft.com>; Thu, 8 Jan 2004 9:18:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67200585 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jan 2004 09:18:01 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jan 2004 09:18:01 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5396A12BFE6 for ; Thu, 8 Jan 2004 06:18:01 -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 15053-01 for ; Thu, 8 Jan 2004 06:18:01 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.73]) by prattle.redback.com (Postfix) with ESMTP id 1B01A12BFE3 for ; Thu, 8 Jan 2004 06:18:00 -0800 (PST) References: <001301c3d5bb$81e86e80$5f04060a@future.futsoft.com> Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Thu, 8 Jan 2004 09:17:54 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: virtual link transit summary lsa To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <001301c3d5bb$81e86e80$5f04060a@future.futsoft.com> Precedence: list Content-Transfer-Encoding: quoted-printable On Thu, 8 Jan 2004 13:16:20 +0530, Kishore Kumar Y wrote: > backbone transit area 1 area 2 > -----------R1-----------------R2----------------------R3------- > 10.0.0.1 20.0.0.x 30.0.0.x 40.0.0.= 1 > > > i configured a virtual link between router R2 and R3. > the cost for each interface is 10. > > my doubt is at router R3 10.0.0.0 network route entry path type > should be INTER AREA or INTRA AREA. > > according to RFC 2328 section 16.3 > while doing Transit summary lsa calculation path type should remain > same INTRA AREA or INTER AREA found during calculation 16.1 and 16.2 > > i feel path type should be INTRA AREA though the path is through transi= t > area. Kishore, You are connect, it should be type intra-area. You might want to assure the virtual adjacency is in the full state. > > > ******************************************** > Yarlagadda Kishore Kumar > Future Software Ltd., > 480-481, Mount Road, > Nandanam, chennai 600 035 > ph: 91-44-433 0550 Ex -305 (O) > kishoreky@future.futsoft.com > yarlagadda_kk@lycos.com > ******************************************** > > > > > > ***********************************************************************= **** > 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. > ***********************************************************************= **** --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 9 11:30:54 2004 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 KAA07019 for ; Fri, 9 Jan 2004 10:42: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.00C97E04@cherry.ease.lsoft.com>; Wed, 7 Jan 2004 9:41:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67045990 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Jan 2004 09:41:51 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 7 Jan 2004 09:31:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11452; Wed, 7 Jan 2004 09:31:47 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200401071431.JAA11452@ietf.org> Date: Wed, 7 Jan 2004 09:31:47 -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-08.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-08.txt Pages : 107 Date : 2004-1-6 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-08.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-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-mib-update-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-6175051.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mib-update-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mib-update-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-6175051.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 9 22:27:20 2004 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 WAA07130 for ; Fri, 9 Jan 2004 22:27:20 -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 <9.00C9C95F@cherry.ease.lsoft.com>; Fri, 9 Jan 2004 22:27:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67411617 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jan 2004 22:27:17 -0500 Received: from 202.249.37.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jan 2004 22:27:17 -0500 Received: from [202.249.37.12] (sec01.koganei.wide.ad.jp [202.249.37.12]) by ns.koganei.wide.ad.jp (8.12.9/8.12.6) with ESMTP id i0A3R9ke026272 for ; Sat, 10 Jan 2004 12:27:10 +0900 (JST) (envelope-from zhang@koganei.wide.ad.jp) References: <20040108134641.08B6.ZHANG@koganei.wide.ad.jp> <002901c3d5a8$069d4ce0$4703080a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 Message-ID: <20040110121831.CC06.ZHANG@koganei.wide.ad.jp> Date: Sat, 10 Jan 2004 12:26:47 +0900 Reply-To: Mailing List Sender: Mailing List From: Zhang Shu Subject: Re: field length in ospfv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <002901c3d5a8$069d4ce0$4703080a@future.futsoft.com> Precedence: list Content-Transfer-Encoding: 7bit Hi lakshmips, Thank you very much for your reply! I got another question: is there any effort in this wg to clarify this issue or to make rfc2740 more correct? I think this problem can really confuse devoplepers. Regards, Zhang Shu On Thu, 8 Jan 2004 10:56:52 +0530 Lakshmips wrote: > hi, > > Section A.2. rfc 2740 describes the option field. > The option field in all the mentioned packets is 24-bits. > The metric field is also 24-bits. > The "0" occupies 8bits. > > regards > lakshmi priya > -----Original Message----- > From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Zhang > Shu > Sent: Thursday, 8 January 2004 10:37 AM > To: OSPF@peach.ease.lsoft.com > Subject: field length in ospfv3 > > > Hi there, > > Can anyone please tell me what the length of following fields is in > RFC2740? It is difficult to determine them from the packet format in the > RFC and there seems not to be any description of them (I apology if I > missed them). > > 1. Section A.4.4 Network-LSAs > > "0", Options field (right after the LSA header) > > 2. Section A.4.5 Inter-Area-Prefix-LSAs > > "0", Metric field (right after the LSA header) > > 3. Section A.4.6 Inter-Area-Router-LSAs > > "0" ,Options field (right after the LSA header) and the following "0", > Metric field > > Thanks in advance! > > Zhang Shu > > > > *************************************************************************** > 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 Sat Jan 10 06:27:55 2004 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 GAA02365 for ; Sat, 10 Jan 2004 06:27: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 <10.00C9D3EA@cherry.ease.lsoft.com>; Sat, 10 Jan 2004 6:27:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67463432 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 10 Jan 2004 06:27:54 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 10 Jan 2004 06:27:54 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 72B90663F43 for ; Sat, 10 Jan 2004 03:27:53 -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 28787-10 for ; Sat, 10 Jan 2004 03:27:53 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.46]) by prattle.redback.com (Postfix) with ESMTP id D2E09663F49 for ; Sat, 10 Jan 2004 03:27:52 -0800 (PST) Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Sat, 10 Jan 2004 06:27:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: draft-ietf-ospf-mib-update-08.txt - OSPF Version 2 Management Information Base To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable This begins the WG last call for the subject document. The last call peri= od will end three weeks from today at 12:01 AM EST on February 1st, 2004. I want to thank the authors for all their work incorportating OSPF extens= ions into the MIB. Please post comments to this list. Title : OSPF Version 2 Management Information Base Author(s) : S. Giacalone, D. Joyal, R. Coltun, F. Baker Filename : draft-ietf-ospf-mib-update-08.txt Pages : 107 Date : 2004-1-6 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-08.txt Thanks, --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 11 23:53:38 2004 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 XAA00155 for ; Sun, 11 Jan 2004 23:53:38 -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.00C9F26A@cherry.ease.lsoft.com>; 11 Jan 2004 23:53:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67625383 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 11 Jan 2004 23:53:37 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jan 2004 23:53:37 -0500 Received: from smirtoraw2k03 (sjc-vpn4-145.cisco.com [10.21.80.145]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i0C4rZJ04986 for ; Sun, 11 Jan 2004 20:53:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Message-ID: <004f01c3d8c8$09630910$f2ce7243@amer.cisco.com> Date: Sun, 11 Jan 2004 20:53:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: draft-mirtorabi-ospf-tunnel-adjacency-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Folks, A new version of TA has been published http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunnel-adjacenc y-01.txt There was some concerns regarding the recursive TA, discussed during the last ietf meeting. We had some discussion with Acee and we decided that the best way to prevent recursive TA is to allow only backbone to be the transit area. This still honor what TA was initially designed for, namely 1) Use Backbone area as high speed path for non-backbone area ( Intra-area / Inter-area preference ) 2) Use automatic partition repair for non-backbone area when summarization is performed 3) Use TA for multiple non-backbone area path and prevent the cost of adding additional link ( e.g. Hub and Spoke topology) This change will prevent TA to be used for backbone partition repair however there is already a solution for this i.e. VL and having a redundant solution is not required. Comments are welcome, Sina From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 07:58:54 2004 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 HAA24788 for ; Mon, 12 Jan 2004 07:58: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 <22.00C9F8FC@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 7:58:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67679826 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 07:58:51 -0500 Received: from 129.26.8.90 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 07:48:50 -0500 Received: from fokus.fhg.de (dynamis [129.26.13.136]) by mail.bi.fraunhofer.de (8.9.3/8.9.3) with ESMTP id NAA20609 for ; Mon, 12 Jan 2004 13:48:49 +0100 (MET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <400297B1.60503@fokus.fhg.de> Date: Mon, 12 Jan 2004 13:48:49 +0100 Reply-To: Mailing List Sender: Mailing List From: Olaf Menzel Subject: TOS field removal in OSPF for IPv6 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dear OSPF-Group, -------------------- I am working in a EU project called "Daidalos" (http://www.ist-daidalos.org) and I am responsible for routing stuff in fixed and ad-hoc network based on IPv6. For multipath routing path decission I wanted to use OSPF first with DS- field (TOS in IPv4) tracking and later update to IPv6 QOSPF (QoS based OSPF) I just recognized the TOS based routing has been removed in the OSPF IPv6 specification . I wanted to use this feature from OSPF v2 with some enhancements from RFC2676 - "QoS Routing Mechanisms and OSPF Extensions" and port this to IPv6. The routing protocol should support path selection based on the service class of the delivered content. RFC2740: "Type of Service (TOS) has been removed from the OSPFv2 specification [Ref1], and is not encoded within OSPF for IPv6's LSAs." Are there any serious reasons why the OPSF WG has decited to remove "Type of Service - routing" from OSPF for IPv6 ? with regards Olaf Menzel -- Dipl. Ing. Olaf Menzel - System Engineer FOKUS - Fraunhofer Institute for Open Communication Systems: - Competence Center for Advanced Satellite Communication Schloss Birlinghoven, 53754 Sankt Augustin, Germany Phone: +49-2241-14-3494 Mobile: +49-175-2616161 Fax:+49-2241-14-43494 email: olaf.menzel@fokus.fhg.de Internet: http://www.fokus.fhg.de/satcom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 08:05:05 2004 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 IAA25197 for ; Mon, 12 Jan 2004 08:05: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 <1.00C9F93F@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 8:05:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67680576 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 08:05:03 -0500 Received: from 67.100.73.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 08:05:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: TOS field removal in OSPF for IPv6 Thread-Index: AcPZC9VSm3MoeXDYSh++osWH3tjw5wAHkA6A Message-ID: Date: Mon, 12 Jan 2004 05:05:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: TOS field removal in OSPF for IPv6 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Olaf, I guess the reason was that TOS routing was probably never used in = production networks. Is there any particular scenario in mind wrt mobility where TOS might be = useful and current mechanisms dont suffice? Could you elaborate them for = us? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Olaf Menzel Sent: Monday, January 12, 2004 2:49 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: TOS field removal in OSPF for IPv6 Dear OSPF-Group, -------------------- I am working in a EU project called "Daidalos" (http://www.ist-daidalos.org) and I am responsible for routing stuff in fixed and ad-hoc network based on IPv6. For multipath routing path decission I wanted to use OSPF first with DS- field (TOS in IPv4) tracking and later update to IPv6 QOSPF (QoS based OSPF) I just recognized the TOS based routing has been removed in the OSPF IPv6 specification . I wanted to use this feature from OSPF v2 with some enhancements from RFC2676 - "QoS Routing Mechanisms and OSPF Extensions" and port this to IPv6. The routing protocol should support path selection based on the service class of the delivered content. RFC2740: "Type of Service (TOS) has been removed from the OSPFv2 specification [Ref1], and is not encoded within OSPF for IPv6's LSAs." Are there any serious reasons why the OPSF WG has decited to remove "Type of Service - routing" from OSPF for IPv6 ? with regards Olaf Menzel -- Dipl. Ing. Olaf Menzel - System Engineer FOKUS - Fraunhofer Institute for Open Communication Systems: - Competence Center for Advanced Satellite Communication Schloss Birlinghoven, 53754 Sankt Augustin, Germany Phone: +49-2241-14-3494 Mobile: +49-175-2616161 Fax:+49-2241-14-43494 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 =20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 10:13:06 2004 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 KAA01207 for ; Mon, 12 Jan 2004 10:13: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 <3.00C9FC1C@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 10:13:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67707814 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 10:13:00 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 10:13:00 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6066826 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 10:12:59 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040112101123.0196f750@localhost> Date: Mon, 12 Jan 2004 10:12:44 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joel M. Halpern" Subject: Re: TOS field removal in OSPF for IPv6 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <400297B1.60503@fokus.fhg.de> Precedence: list This was removed when OSPF v2 was being advanced on the standards track because the WG could not find two interoperable implementations. To phrase it another way, it was not being implemented, not being used, and not being requested, so we removed it. WHen the OSPF for IPv6 work was being done no effort was made to restore this as there was no driver to do so. Yours, Joel M. Halpern At 01:48 PM 1/12/2004 +0100, you wrote: >Dear OSPF-Group, >-------------------- >I am working in a EU project called "Daidalos" >(http://www.ist-daidalos.org) and I am responsible for >routing stuff in fixed and ad-hoc network based on IPv6. For multipath >routing path decission I wanted to >use OSPF first with DS- field (TOS in IPv4) tracking and later update >to IPv6 QOSPF (QoS based OSPF) >I just recognized the TOS based routing has been removed in the OSPF >IPv6 specification . >I wanted to use this feature from OSPF v2 with some enhancements from >RFC2676 - >"QoS Routing Mechanisms and OSPF Extensions" and port this to IPv6. >The routing protocol >should support path selection based on the service class of the >delivered content. > >RFC2740: > >"Type of Service (TOS) has been removed from >the OSPFv2 specification [Ref1], and is not encoded within OSPF for >IPv6's LSAs." > >Are there any serious reasons why the OPSF WG has decited to remove >"Type of Service - routing" from OSPF for IPv6 ? > > >with regards > >Olaf Menzel > >-- >Dipl. Ing. Olaf Menzel - System Engineer >FOKUS - Fraunhofer Institute for Open Communication Systems: >- Competence Center for Advanced Satellite Communication >Schloss Birlinghoven, 53754 Sankt Augustin, Germany >Phone: +49-2241-14-3494 Mobile: +49-175-2616161 Fax:+49-2241-14-43494 >email: olaf.menzel@fokus.fhg.de Internet: http://www.fokus.fhg.de/satcom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 11:12:39 2004 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 LAA03990 for ; Mon, 12 Jan 2004 11:12:38 -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 <10.00C9FD89@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 11:12:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67713123 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 11:12:29 -0500 Received: from 195.117.137.85 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 11:12:29 -0500 Received: from localhost (localhost [127.0.0.1]) by nsm.pl (Postfix) with ESMTP id 04D116AFCC for ; Mon, 12 Jan 2004 17:12:24 +0100 (CET) Received: from nsm.pl ([195.117.137.85]) by localhost (nsm.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31592-09 for ; Mon, 12 Jan 2004 17:12:23 +0100 (CET) Received: from sqix (hub3.chelmnet.pl [195.117.2.99]) by nsm.pl (Postfix) with SMTP id 5EB086AFC5 for ; Mon, 12 Jan 2004 17:12:23 +0100 (CET) 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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal X-Virus-Scanned: NSM AntiVirus System Message-ID: Date: Mon, 12 Jan 2004 17:12:29 +0100 Reply-To: Mailing List Sender: Mailing List From: Arkadiusz Binder Subject: Re: TOS field removal in OSPF for IPv6 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit > Hi Olaf, > > I guess the reason was that TOS routing was probably never used > in production networks. > > Is there any particular scenario in mind wrt mobility where TOS > might be useful and current mechanisms dont suffice? Could you > elaborate them for us? Hi, i have some needs for that. I have a network with different ISP (about 4). Any of them prohibit traffic with sources IP different than they provide. Here is my diagram: A--B--C--ISP1 | | | | | | D--E--F--ISP2 | | ISP3 How to use all of accessible IP-spaces provided by ISP1,2,3 ? My solution was to use ip-precendence/TOS for marking all traffic arriving at any A,B,C...F router LAN interfaces - with 0x1 for ISP1, 0x2 for ISP2, 0x3 for ISP3. Every C,D,F router distribute default route - router C distribute default route 0x1 , D=0x3, F=0x2. In such situation every incomming packet with different routes per different TOS could exit from our IGP properly (to correct ISP). I have problem in my network, i use the biggest ISP1 link in my IGP (OSPF), any other ISP2,3 is used only at the router D or router F, without any redistribution. I can't see any other possibility of solving my problem within single IGP. Sure, i can have different route-tags and several default routes, then distribute them to different kernel-routing-tables, then put ingress packets in correct tables at every hop. What is the best solution for that? I use zebra/quagga routing daemon and cisco's. Arkadiusz Binder From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 12:21:17 2004 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 MAA06601 for ; Mon, 12 Jan 2004 12:21: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 <19.00C9FCD0@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 12:21:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67719251 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 12:21:16 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 12:21:16 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA19959 for ; Mon, 12 Jan 2004 12:21:08 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26114 for ; Mon, 12 Jan 2004 12:21:09 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Jan 2004 12:21:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB7179@vie-msgusr-01.dc.fore.com> Date: Mon, 12 Jan 2004 12:21:05 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: TOS field removal in OSPF for IPv6 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Menzel, There is no relation between IPv4 TOS and IPv6 traffic class. RFC 3260 overwrites both of the files for diffserv. The correct answer is, OSPFv2 is for IPv4. OSPFv2 once supported TOS based routing. OSPFv2 TOS routing is not standardized because of lack of implementation/deployment. More over, RFC 2676 is an experimental RFC. Coming to IPv6. There is no TOS field as such in IPv6 header. There are {Traffic class, Flow label} in IPv6 header. At the time of IPv6 specification Traffic Class is almost same as TOS. But, it's real use was never defined precisely. That is why OSPFv3 never incorporated Traffic Class routing. After that, Diffserv changed semantics of IPv4 TOS and IPv6 TC fields couple of times. The recent one is in RFC 3260. Coming to MPLS for IPv4. Yes. There is a similar TOS routing in MPLS. Look at: http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt The difference are very subtle and indirect. But, IPv4 TOS routing and MPLS routing with different IGP metrics are one and the same. My final suggestion is: if you are doing some experimentation and/or deployment of a network with out any interoperability issues (i.e., for example, if you run whole network with your own box) then go ahead with your proprietary extensions to OSPF over IPv6 TC routing (just like OSPF over IPv4 TOS routing). If successful and possible, spin a named draft. Hope that will be considered by IETF (like RFC 2676). -- Venkata. -> At 01:48 PM 1/12/2004 +0100, you wrote: -> >Dear OSPF-Group, -> >-------------------- -> >I am working in a EU project called "Daidalos" -> >(http://www.ist-daidalos.org) and I am responsible for -> >routing stuff in fixed and ad-hoc network based on IPv6. -> For multipath -> >routing path decission I wanted to -> >use OSPF first with DS- field (TOS in IPv4) tracking and -> later update -> >to IPv6 QOSPF (QoS based OSPF) -> >I just recognized the TOS based routing has been removed -> in the OSPF -> >IPv6 specification . -> >I wanted to use this feature from OSPF v2 with some -> enhancements from -> >RFC2676 - -> >"QoS Routing Mechanisms and OSPF Extensions" and port this to IPv6. -> >The routing protocol -> >should support path selection based on the service class of the -> >delivered content. -> > -> >RFC2740: -> > -> >"Type of Service (TOS) has been removed from -> >the OSPFv2 specification [Ref1], and is not encoded within OSPF for -> >IPv6's LSAs." -> > -> >Are there any serious reasons why the OPSF WG has decited to remove -> >"Type of Service - routing" from OSPF for IPv6 ? -> > -> > -> >with regards -> > -> >Olaf Menzel -> > -> >-- -> >Dipl. Ing. Olaf Menzel - System Engineer -> >FOKUS - Fraunhofer Institute for Open Communication Systems: -> >- Competence Center for Advanced Satellite Communication -> >Schloss Birlinghoven, 53754 Sankt Augustin, Germany -> >Phone: +49-2241-14-3494 Mobile: +49-175-2616161 -> Fax:+49-2241-14-43494 -> >email: olaf.menzel@fokus.fhg.de Internet: http://www.fokus.fhg.de/satcom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 15:44:57 2004 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 PAA18129 for ; Mon, 12 Jan 2004 15:44:57 -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.00CA029B@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 15:44:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67737129 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 15:44:55 -0500 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 15:44:55 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA00990 for ; Mon, 12 Jan 2004 12:44:44 -0800 (PST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id MAA14058 for ; Mon, 12 Jan 2004 12:44:53 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i0CKhjn20987 for ; Mon, 12 Jan 2004 14:43:45 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 12 Jan 2004 12:39:12 -0800 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: TOS field removal in OSPF for IPv6 Thread-Index: AcPZRTdVCVG1Y9gOR4CXc4XYP5YjBAAAdzUQ X-OriginalArrivalTime: 12 Jan 2004 20:39:12.0885 (UTC) FILETIME=[23432250:01C3D94C] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B608E@xch-nw-27.nw.nos.boeing.com> Date: Mon, 12 Jan 2004 12:39:12 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: TOS field removal in OSPF for IPv6 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Naidu, Venkata [mailto:Venkata.Naidu@MARCONI.COM] > Sent: Monday, January 12, 2004 9:21 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: TOS field removal in OSPF for IPv6 >=20 > Coming to MPLS for IPv4. Yes. There is a similar TOS routing > in MPLS. Look at: > =20 > http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric- > igp-02.txt > The difference are very subtle and indirect. But, IPv4 TOS > routing and MPLS routing with different IGP metrics are one > and the same. The approach cited above works for at most two TOS-based metrics. =20 However, there doesn't appear to be a more general OSPFv3 mechanism=20 for assigning different metrics to different traffic classes, to=20 effect policy routing based on service classes (the problem that=20 started this thread). Tom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 16:08:46 2004 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 QAA19504 for ; Mon, 12 Jan 2004 16:08:45 -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 <12.00CA02CF@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 16:08:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67739370 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 16:08:44 -0500 Received: from 195.117.137.85 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 16:08:43 -0500 Received: from localhost (localhost [127.0.0.1]) by nsm.pl (Postfix) with ESMTP id AEBEF6AFC5 for ; Mon, 12 Jan 2004 22:08:34 +0100 (CET) Received: from nsm.pl ([195.117.137.85]) by localhost (nsm.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10286-04 for ; Mon, 12 Jan 2004 22:08:34 +0100 (CET) Received: from sqix (hub3.chelmnet.pl [195.117.2.99]) by nsm.pl (Postfix) with SMTP id 828356AFA7 for ; Mon, 12 Jan 2004 22:08:29 +0100 (CET) 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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal X-Virus-Scanned: NSM AntiVirus System Message-ID: Date: Mon, 12 Jan 2004 22:08:37 +0100 Reply-To: Mailing List Sender: Mailing List From: Arkadiusz Binder Subject: Re: TOS field removal in OSPF for IPv6 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55FB7179@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit > http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt (i read this) > The difference are very subtle and indirect. But, IPv4 TOS > routing and MPLS routing with different IGP metrics are one > and the same. Ok, you are right (in math), but the difference is that we need to support MPLS (more troubles) In my case much simplier would be to use ipv4 TOS field and different TOS routes for different own policies /external routes/source routing/ but i can't find it working on my linux . A.Binder From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 20:07:28 2004 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 UAA03009 for ; Mon, 12 Jan 2004 20:07:27 -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 <10.00CA08B0@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 20:07:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67758744 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 20:07:20 -0500 Received: from 202.43.216.209 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 20:07:20 -0500 Received: from [202.96.96.35] by web15406.mail.cnb.yahoo.com via HTTP; Tue, 13 Jan 2004 09:07:17 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20040113010717.3502.qmail@web15406.mail.cnb.yahoo.com> Date: Tue, 13 Jan 2004 09:07:17 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?q?Jing=20Shen?= Subject: Re: TOS field removal in OSPF for IPv6 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 8bit Hi, > I have problem in my network, i use the biggest ISP1 > link in my IGP (OSPF), > any other ISP2,3 is used only at the router D or > router F, without any > redistribution. > I don't understand here clearly. Have you really implemented solution above in your network? or you just set up traffic classification on router to ISP1 and redirect those traffic with IP from ISP2 ( ISP3) to appropriate router? If so, that does not relate to OSPF. I'm not familiar with zebra, but in cisco OSPF FAQ it states: " Q: Does the Cisco OSPF implementation support IP TOS-based routing? A: Cisco OSPF only supports TOS 0. This means that routers route all packets on the TOS 0 path, eliminating the need to calculate non-zero TOS paths. " I don't know wether your network is one with hundreds of routers, if it just consist of less than 10 router policy based routing could be set up easily at each router. And, it could be easily set up two or more optional routes for each destination. To ToS based routing in OSPF, I don't think it should be based on ToS/"traffic class" but to based on DSCP which is under hot discussion now. regards Jing Shen 'spam control' __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 12 22:21:20 2004 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 WAA09932 for ; Mon, 12 Jan 2004 22:21:19 -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.00CA09B6@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 22:21:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67768960 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 22:21:11 -0500 Received: from 192.11.222.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 22:21:11 -0500 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0D3L0622101 for ; Mon, 12 Jan 2004 21:21:02 -0600 (CST) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jan 2004 11:20:49 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Message-ID: <31C0F08B0D18D511ACC800508BAE7B4707F47E19@CI0026EXCH001U> Date: Tue, 13 Jan 2004 11:20:45 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Re: draft-mirtorabi-ospf-tunnel-adjacency-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I've a question related to the first application of TA, i.e., use backbone area as high speed path for non-backbone area. In my opinion, the reason of using TA to do this is that, in OSPF intra-area path is preferred over inter-area path. My question is, what will happen if we remove the preference? When there are one intra-area path and one inter-area path to the same destination, we choose one by comparing their metrics. Is there any serious consequence? Thank you. Keqin Li > -----Original Message----- > From: Sina Mirtorabi [mailto:sina@CISCO.COM] > Sent: Monday, January 12, 2004 12:54 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: draft-mirtorabi-ospf-tunnel-adjacency-01.txt > > > Folks, > > A new version of TA has been published > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunne > l-adjacenc > y-01.txt > > > There was some concerns regarding the recursive TA, discussed > during the > last ietf meeting. We had some discussion with Acee and we > decided that > the best way to prevent recursive TA is to allow only > backbone to be the > transit area. > > This still honor what TA was initially designed for, namely > > 1) Use Backbone area as high speed path for non-backbone area ( > Intra-area / Inter-area preference ) > 2) Use automatic partition repair for non-backbone area when > summarization is performed > 3) Use TA for multiple non-backbone area path and prevent the cost of > adding additional link ( e.g. Hub and Spoke topology) > > This change will prevent TA to be used for backbone partition repair > however there is already a solution for this i.e. VL and having a > redundant solution is not required. > > > Comments are welcome, > > Sina > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 13 00:16:12 2004 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 AAA13259 for ; Tue, 13 Jan 2004 00:16: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 <17.00CA0F75@cherry.ease.lsoft.com>; Tue, 13 Jan 2004 0:14:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67785603 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jan 2004 00:13:59 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jan 2004 00:13:58 -0500 Received: from smirtoraw2k03 (sjc-vpn1-883.cisco.com [10.21.99.115]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i0D5DqJ11684 for ; Mon, 12 Jan 2004 21:13:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: <000901c3d994$0c0cd2a0$f2ce7243@amer.cisco.com> Date: Mon, 12 Jan 2004 21:13:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-mirtorabi-ospf-tunnel-adjacency-01.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B4707F47E19@CI0026EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit Kequin, ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->Behalf Of Li, Ke Qin (Peter) ->Sent: Monday, January 12, 2004 7:21 PM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: Re: draft-mirtorabi-ospf-tunnel-adjacency-01.txt -> -> ->Hi, -> ->I've a question related to the first application of TA, i.e., ->use backbone area as high speed path for non-backbone area. ->In my opinion, the reason of using TA to do this is that, in ->OSPF intra-area path is preferred over inter-area path. -> ->My question is, what will happen if we remove the preference? ->When there are one intra-area path and one inter-area path to ->the same destination, we choose one by comparing their ->metrics. Is there any serious consequence? Since the summary cost is based on the intra-area cost theoretically you should not have a routing loop however there are few problems - All routers must behave the same which means that you have a backward compatibility problem to resolve as otherwise you encounter routing loops - When you summarize you will hide detail cost information and can easily go back to routing loop. For example imagine that you want to go from R1 to R2 in area 1 and have both intra-area and Inter-area path. When you chose your Inter-area path and send the packet via backbone, If the backbone routers receive only summary for area 1 then the path can go back to the ABR that R1 chose to send the packet in first place and you have a routing loop Thanks Sina -> ->Thank you. -> ->Keqin Li -> ->> -----Original Message----- ->> From: Sina Mirtorabi [mailto:sina@CISCO.COM] ->> Sent: Monday, January 12, 2004 12:54 ->> To: OSPF@PEACH.EASE.LSOFT.COM ->> Subject: draft-mirtorabi-ospf-tunnel-adjacency-01.txt ->> ->> ->> Folks, ->> ->> A new version of TA has been published ->> ->> http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunne ->> l-adjacenc ->> y-01.txt ->> ->> ->> There was some concerns regarding the recursive TA, ->discussed during ->> the last ietf meeting. We had some discussion with Acee and we ->> decided that ->> the best way to prevent recursive TA is to allow only ->> backbone to be the ->> transit area. ->> ->> This still honor what TA was initially designed for, namely ->> ->> 1) Use Backbone area as high speed path for non-backbone area ( ->> Intra-area / Inter-area preference ) ->> 2) Use automatic partition repair for non-backbone area when ->> summarization is performed ->> 3) Use TA for multiple non-backbone area path and prevent ->the cost of ->> adding additional link ( e.g. Hub and Spoke topology) ->> ->> This change will prevent TA to be used for backbone ->partition repair ->> however there is already a solution for this i.e. VL and having a ->> redundant solution is not required. ->> ->> ->> Comments are welcome, ->> ->> Sina ->> -> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 13 03:05:04 2004 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 DAA00798 for ; Tue, 13 Jan 2004 03:05: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 <1.00CA116A@cherry.ease.lsoft.com>; Tue, 13 Jan 2004 3:05:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67798120 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jan 2004 03:05:00 -0500 Received: from 192.11.226.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jan 2004 03:05:00 -0500 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0D84sa15626 for ; Tue, 13 Jan 2004 02:04:55 -0600 (CST) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jan 2004 16:04:52 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="gb2312" Message-ID: <31C0F08B0D18D511ACC800508BAE7B4707F47E1A@CI0026EXCH001U> Date: Tue, 13 Jan 2004 16:04:43 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Re: draft-mirtorabi-ospf-tunnel-adjacency-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I've constructed an example according to your description about routing loop caused by summarization. --- 5---|w|---5 | --- | | | --- --- ======|x|=====|y|===== --- --- | | | --- | 20---|t|---5 --- In this graph, '=' is the border of area. Above the border is area 0, below it is area 1. x and y are ABRs. Link costs are depicted in the graph. Case 1: no range is configured in x and y. In this case, x advertises summary-LSA with destination t and metric 20. y advertises summary-LSA with destination t and metric 5. Thus, x has an intra-area route to t with cost 20, and an inter-area route to t with cost 15. x chooses the inter-area route. w chooses inter-area route to t throught y. So, there is no routing loop. Case 2: a range m is configure in y. m covers t. In this case, x has an intra-area route to t, and an inter-area route to m. When forward packet destined to t, x chooses the intra-area route according to the longest match rule. So, there is no routing loop. Thus, in my opionion, there is no routing loop, but still suboptimal routing. What's your opinion about this? Thank you. Keqin Li >Since the summary cost is based on the intra-area cost theoretically you >should not have a routing loop however there are few problems > >- All routers must behave the same which means that you have a backward >compatibility problem to resolve as otherwise you encounter routing >loops > >- When you summarize you will hide detail cost information and can >easily go back to routing loop. For example imagine that you want to go >from R1 to R2 in area 1 and have both intra-area and Inter-area path. >When you chose your Inter-area path and send the packet via backbone, If >the backbone routers receive only summary for area 1 then the path can >go back to the ABR that R1 chose to send the packet in first place and >you have a routing loop > >Thanks >Sina Keqin Li Bell Labs Research China Tel: 86-10-68748088-8438 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 13 12:09:26 2004 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 MAA25784 for ; Tue, 13 Jan 2004 12:09:23 -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.00CA19D2@cherry.ease.lsoft.com>; Tue, 13 Jan 2004 12:09:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67858192 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jan 2004 12:09:17 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jan 2004 12:09:17 -0500 Received: from smirtoraw2k03 (dhcp-171-69-100-248.cisco.com [171.69.100.248]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i0DH9GJ06065 for ; Tue, 13 Jan 2004 09:09:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: <003801c3d9f7$fa6f6620$f2ce7243@amer.cisco.com> Date: Tue, 13 Jan 2004 09:09:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-mirtorabi-ospf-tunnel-adjacency-01.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B4707F47E1A@CI0026EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit Kequin, ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->Behalf Of Li, Ke Qin (Peter) ->Sent: Tuesday, January 13, 2004 12:05 AM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: Re: draft-mirtorabi-ospf-tunnel-adjacency-01.txt -> -> ->Hi, -> ->I've constructed an example according to your description ->about routing loop caused by summarization. -> -> --- -> 5---|w|---5 -> | --- | -> | | -> --- --- ->======|x|=====|y|===== -> --- --- -> | | -> | --- | -> 20---|t|---5 -> --- -> ->In this graph, '=' is the border of area. Above the border is ->area 0, below it is area 1. x and y are ABRs. Link costs are ->depicted in the graph. -> ->Case 1: no range is configured in x and y. -> ->In this case, x advertises summary-LSA with destination t and ->metric 20. y advertises summary-LSA with destination t and ->metric 5. Thus, x has an intra-area route to t with cost 20, ->and an inter-area route to t with cost 15. x chooses the ->inter-area route. w chooses inter-area route to t throught y. ->So, there is no routing loop. Yes, As I said since the cost of the summary is based on intra-area cost you should not have routing loop -> ->Case 2: a range m is configure in y. m covers t. -> ->In this case, x has an intra-area route to t, and an ->inter-area route to m. When forward packet destined to t, x ->chooses the intra-area route according to the longest match ->rule. So, there is no routing loop. -> ->Thus, in my opionion, there is no routing loop, but still ->suboptimal routing. Actually if you summarize you would install a discard route and ignore the remote summary in that case you would only have an intra-area path Any way the main idea is to create a path through backbone _visible_ to internal routers in the non-backbone area. Since the ABR will not generate summary back to the internal area, the Inter-area path is only visible to border routers and not very useful to internal routers... Sina -> ->What's your opinion about this? -> ->Thank you. -> ->Keqin Li -> ->>Since the summary cost is based on the intra-area cost theoretically ->>you should not have a routing loop however there are few problems ->> ->>- All routers must behave the same which means that you have ->a backward ->>compatibility problem to resolve as otherwise you encounter routing ->>loops ->> ->>- When you summarize you will hide detail cost information and can ->>easily go back to routing loop. For example imagine that you ->want to go ->>from R1 to R2 in area 1 and have both intra-area and ->Inter-area path. ->>When you chose your Inter-area path and send the packet via ->backbone, ->>If the backbone routers receive only summary for area 1 then ->the path ->>can go back to the ABR that R1 chose to send the packet in ->first place ->>and you have a routing loop ->> ->>Thanks ->>Sina -> ->Keqin Li ->Bell Labs Research China ->Tel: 86-10-68748088-8438 -> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 13 13:48:03 2004 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 NAA02952 for ; Tue, 13 Jan 2004 13:48: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 <5.00CA1B8B@cherry.ease.lsoft.com>; Tue, 13 Jan 2004 13:47:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67868364 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jan 2004 13:47:50 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jan 2004 13:47:50 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3AF3E6050C8; Tue, 13 Jan 2004 10:47:49 -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 03889-05; Tue, 13 Jan 2004 10:47:49 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.46]) by prattle.redback.com (Postfix) with ESMTP id F35E76050C5; Tue, 13 Jan 2004 10:47:47 -0800 (PST) References: Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Tue, 13 Jan 2004 13:47:33 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: WG Last Call for draft-ietf-ospf-ospfv3-auth-04.txt - Authentication/Confidentiality for OSPFv3 Comments: To: Bill Fenner , Alex Zinin , IESG Secretary To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable This WG last call has completed and the subject document will be submitte= d to the IESG for evaluation. On Fri, 12 Dec 2003 11:14:56 -0500, Acee Lindem wrote: > > This begins the WG last call for the subject document. Due to the holid= ays, > we'll have an extended last call period ending at 12:01 AM EST on Janua= ry > 13th, 2004. > > Thanks, > Acee --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 13 13:55:36 2004 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 NAA03504 for ; Tue, 13 Jan 2004 13:55:35 -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.00CA1B48@cherry.ease.lsoft.com>; Tue, 13 Jan 2004 13:55:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67868861 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jan 2004 13:55:24 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jan 2004 13:55:24 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 574B05F574B; Tue, 13 Jan 2004 10:55:23 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05276-02; Tue, 13 Jan 2004 10:55:23 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.46]) by prattle.redback.com (Postfix) with ESMTP id CF5BC5F5747; Tue, 13 Jan 2004 10:55:21 -0800 (PST) References: Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Tue, 13 Jan 2004 13:55:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: WG Last Call for draft-ietf-ospf-ospfv3-auth-04.txt - Authentication/Confidentiality for OSPFv3 Comments: To: Bill Fenner , Alex Zinin , IESG Secretary To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable On Tue, 13 Jan 2004 13:47:33 -0500, Acee Lindem wrote: > This WG last call has completed and the subject document will be submit= ted > to the IESG for evaluation. Opps - I believe I missed a phase here. The subject document will be subm= itted to the routing area ADs for evaluation prior to the full IESG. Sorry for = the confusion. > > > On Fri, 12 Dec 2003 11:14:56 -0500, Acee Lindem wrot= e: > >> >> This begins the WG last call for the subject document. Due to the holi= days, >> we'll have an extended last call period ending at 12:01 AM EST on Janu= ary >> 13th, 2004. >> >> Thanks, >> Acee > > > --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 14 16:54:12 2004 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 QAA16234 for ; Wed, 14 Jan 2004 16:54: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 <14.00CA3C29@cherry.ease.lsoft.com>; Wed, 14 Jan 2004 16:54:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68024814 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Jan 2004 16:54:10 -0500 Received: from 207.159.120.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Jan 2004 16:54:06 -0500 Received: by xprdmailfe2.nwk.excite.com (Postfix, from userid 110) id 78AB28AEE0; Wed, 14 Jan 2004 16:54:06 -0500 (EST) Received: from [64.47.48.10] by xprdmailfe2.nwk.excite.com via HTTP; Wed, 14 Jan 2004 16:54:06 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: <20040114215406.78AB28AEE0@xprdmailfe2.nwk.excite.com> Date: Wed, 14 Jan 2004 16:54:06 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Something wrong with IETF WG web pages To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, The IETF WG pages seem to have reverted to a copy from November. Can somebody let them know something is wrong? Thanks, Don _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 14 16:59:43 2004 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 QAA16615 for ; Wed, 14 Jan 2004 16:59:41 -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 <9.00CA3C1F@cherry.ease.lsoft.com>; Wed, 14 Jan 2004 16:59:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68025168 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Jan 2004 16:59:33 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Jan 2004 16:59:33 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Agt2y-000ESj-FS; Wed, 14 Jan 2004 21:59:32 +0000 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) References: <20040114215406.78AB28AEE0@xprdmailfe2.nwk.excite.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18315625398.20040114135215@psg.com> Date: Wed, 14 Jan 2004 13:52:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Something wrong with IETF WG web pages Comments: To: Don Goodspeed To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20040114215406.78AB28AEE0@xprdmailfe2.nwk.excite.com> Precedence: list Content-Transfer-Encoding: 7bit Don, Yes, something is wrong indeed. I'll notify the secretariat. -- Alex http://www.psg.com/~zinin/ Wednesday, January 14, 2004, 1:54:06 PM, Don Goodspeed wrote: > All, > The IETF WG pages seem to have reverted to a copy from November. > Can somebody let them know something is wrong? > Thanks, > Don > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Thu Jan 15 16:20:19 2004 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 QAA29115 for ; Thu, 15 Jan 2004 16:20:11 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <1.003CCF1F@grape.ease.lsoft.com>; Thu, 15 Jan 2004 16:20:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68174221 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Jan 2004 16:20:09 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 15 Jan 2004 16:10:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28518; Thu, 15 Jan 2004 16:10:07 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200401152110.QAA28518@ietf.org> Date: Thu, 15 Jan 2004 16:10:07 -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-2547-dnbit-03.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 Filename : draft-ietf-ospf-2547-dnbit-03.txt Pages : 8 Date : 2004-1-15 This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides 'BGP/MPLS IP VPN' service to a customer, and the customer uses OSPF to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPF from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of converting the routes from OSPF to BGP and back to OSPF, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE, and should be ignored by any other PEs that see it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-2547-dnbit-03.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-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-2547-dnbit-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-15152539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-2547-dnbit-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-2547-dnbit-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-15152539.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 09:48:13 2004 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 JAA15972 for ; Fri, 16 Jan 2004 09:48:13 -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.00CA73DD@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 9:48:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68288810 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 09:48:10 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 09:48:10 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 762829ECD2E for ; Fri, 16 Jan 2004 06:48:05 -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 12984-02 for ; Fri, 16 Jan 2004 06:48:05 -0800 (PST) Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id D79639ECD2B for ; Fri, 16 Jan 2004 06:48:04 -0800 (PST) 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <4007F9F4.8060901@redback.com> Date: Fri, 16 Jan 2004 09:49:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I believe that for the foreseeable future the vast majority of networks will be fixed (although they may support wireless hosts). Based on this belief and the fact that what is being proposed for MANET is very different from base OSPFv3 I'd like to propose the following design points for the work: 1. A fixed network OSPFv3 implementation shouldn't require changes to fully interoperate with an OSPFv3 implementation supporting the MANET extensions. 2. The MANET extensions should be limited to wireless interfaces (or whatever level of segregation we end up with). 3. As much as possible, an OSPFv3 implementation with the MANET extensions should be a proper subset of an OSPFv3 implementation without the extensions. In other words, we should be extremely suspect of changes to basic OSPFv3 mechanisms. Thanks, -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 12:00:25 2004 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 MAA21399 for ; Fri, 16 Jan 2004 12:00:22 -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.00CA7708@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 12:00:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68296365 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 11:59:50 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 11:59:50 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26714 for ; Fri, 16 Jan 2004 11:59:48 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21928 for ; Fri, 16 Jan 2004 11:59:49 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Jan 2004 11:59:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB718B@vie-msgusr-01.dc.fore.com> Date: Fri, 16 Jan 2004 11:59:38 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Acee, Your proposal is reasonable. -> I believe that for the foreseeable future the vast majority of -> networks will be fixed (although they may support wireless hosts). -> Based on this belief and the fact that what is being proposed for -> MANET is very different from base OSPFv3 I'd like to propose the -> following design points for the work: -> -> 1. A fixed network OSPFv3 implementation shouldn't require -> changes to fully interoperate with an OSPFv3 implementation -> supporting the MANET extensions. -> 2. The MANET extensions should be limited to wireless -> interfaces (or -> whatever level of segregation we end up with). -> 3. As much as possible, an OSPFv3 implementation with the MANET -> extensions should be a proper subset of an OSPFv3 -> implementation -> without the extensions. In other words, we should be extremely -> suspect of changes to basic OSPFv3 mechanisms. I don't know whether my proposal has already been suggested. Here it is: If OSPFv3 changes to support MANET is so harmful for existing fixed OSPFv3 operation. And if MANET thinks that OSPF is a suitable protocol for their requirements, then it will be a good idea to start OSPFv4 targeted only to support IPv6 MANET requirements. In such a case, OSPFv4 will satisfy all the above design requirements proposed by you. Everybody will be happy. What is your opinion ? Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 12:38:33 2004 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 MAA22686 for ; Fri, 16 Jan 2004 12:38: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 <3.00CA77E9@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 12:38:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68301368 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 12:38:32 -0500 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 12:38:31 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA06077 for ; Fri, 16 Jan 2004 09:38:19 -0800 (PST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id JAA19745 for ; Fri, 16 Jan 2004 09:38:30 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i0GHbMn10618 for ; Fri, 16 Jan 2004 11:37:22 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Fri, 16 Jan 2004 09:37:21 -0800 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: Proposal for OSPF MANET Extensions Design Points Thread-Index: AcPcP/6ylPkptm9gQ623lAg2NvYRTAAFJV7Q X-OriginalArrivalTime: 16 Jan 2004 17:37:21.0502 (UTC) FILETIME=[653937E0:01C3DC57] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B60AC@xch-nw-27.nw.nos.boeing.com> Date: Fri, 16 Jan 2004 09:37:21 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Friday, January 16, 2004 6:49 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Proposal for OSPF MANET Extensions Design Points >=20 >=20 > I believe that for the foreseeable future the vast majority of > networks will be fixed (although they may support wireless hosts). > Based on this belief and the fact that what is being proposed for > MANET is very different from base OSPFv3 I'd like to propose the > following design points for the work: >=20 > 1. A fixed network OSPFv3 implementation shouldn't require > changes to fully interoperate with an OSPFv3 implementation > supporting the MANET extensions. > 2. The MANET extensions should be limited to wireless=20 > interfaces (or > whatever level of segregation we end up with). > 3. As much as possible, an OSPFv3 implementation with the MANET > extensions should be a proper subset of an OSPFv3=20 > implementation > without the extensions. In other words, we should be extremely > suspect of changes to basic OSPFv3 mechanisms. >=20 I agree with 1 and 2. As for 3, extensions cannot be a proper subset by definition (perhaps "superset" is intended?). While I sympathize=20 with the last sentence of 3, I think that being too conservative in the possible design of the extensions will constrain the achievable performance. I would rather state that "For the MANET extensions,=20 departures from basic OSPFv3 mechanisms should be justified by suitable=20 performance benefits." Tom From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 13:01:38 2004 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 NAA23299 for ; Fri, 16 Jan 2004 13:01:38 -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 <17.00CA785C@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 13:01:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68303446 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 13:01:31 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 13:01:31 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id ED79451732D for ; Fri, 16 Jan 2004 10:01:30 -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 29167-07 for ; Fri, 16 Jan 2004 10:01:30 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.56]) by prattle.redback.com (Postfix) with SMTP id 61E35517320 for ; Fri, 16 Jan 2004 10:01:24 -0800 (PST) References: <39469E08BD83D411A3D900204840EC55FB718B@vie-msgusr-01.dc.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <00d601c3dc5a$bf501610$0302a8c0@aceeinspiron> Date: Fri, 16 Jan 2004 13:01:20 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Venkata, ----- Original Message ----- From: "Naidu, Venkata" To: Sent: Friday, January 16, 2004 11:59 AM Subject: Re: Proposal for OSPF MANET Extensions Design Points > Hi Acee, > > Your proposal is reasonable. > > -> I believe that for the foreseeable future the vast majority of > -> networks will be fixed (although they may support wireless hosts). > -> Based on this belief and the fact that what is being proposed for > -> MANET is very different from base OSPFv3 I'd like to propose the > -> following design points for the work: > -> > -> 1. A fixed network OSPFv3 implementation shouldn't require > -> changes to fully interoperate with an OSPFv3 implementation > -> supporting the MANET extensions. > -> 2. The MANET extensions should be limited to wireless > -> interfaces (or > -> whatever level of segregation we end up with). > -> 3. As much as possible, an OSPFv3 implementation with the MANET > -> extensions should be a proper subset of an OSPFv3 > -> implementation > -> without the extensions. In other words, we should be extremely > -> suspect of changes to basic OSPFv3 mechanisms. > > I don't know whether my proposal has already been suggested. > Here it is: If OSPFv3 changes to support MANET is so harmful > for existing fixed OSPFv3 operation. And if MANET thinks that > OSPF is a suitable protocol for their requirements, then it > will be a good idea to start OSPFv4 targeted only to support > IPv6 MANET requirements. > > In such a case, OSPFv4 will satisfy all the above design > requirements proposed by you. Everybody will be happy. > What is your opinion ? I'm not convinced we need a new protocol at this point. There are a number of disadvantages of a new protocol including 1) Migration of fixed networks in environments containing both MANET and fixed nodes 2) Dual protocol maintenance for new features (standards, development, deployment). > > Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 13:28:22 2004 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 NAA24179 for ; Fri, 16 Jan 2004 13:28:21 -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 <4.00CA7854@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 13:28:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68304694 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 13:28:20 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 13:28:20 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 14AE97291C7 for ; Fri, 16 Jan 2004 10:28:20 -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 03513-10 for ; Fri, 16 Jan 2004 10:28:19 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.56]) by prattle.redback.com (Postfix) with SMTP id 7B6B97291C4 for ; Fri, 16 Jan 2004 10:28:19 -0800 (PST) References: <6938661A6EDA8A4EA8D1419BCE46F24C026B60AC@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <014401c3dc5e$81f41740$0302a8c0@aceeinspiron> Date: Fri, 16 Jan 2004 13:28:15 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Tom, ----- Original Message ----- From: "Henderson, Thomas R" To: Sent: Friday, January 16, 2004 12:37 PM Subject: Re: Proposal for OSPF MANET Extensions Design Points > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Friday, January 16, 2004 6:49 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Proposal for OSPF MANET Extensions Design Points > > > I believe that for the foreseeable future the vast majority of > networks will be fixed (although they may support wireless hosts). > Based on this belief and the fact that what is being proposed for > MANET is very different from base OSPFv3 I'd like to propose the > following design points for the work: > > 1. A fixed network OSPFv3 implementation shouldn't require > changes to fully interoperate with an OSPFv3 implementation > supporting the MANET extensions. > 2. The MANET extensions should be limited to wireless > interfaces (or > whatever level of segregation we end up with). > 3. As much as possible, an OSPFv3 implementation with the MANET > extensions should be a proper subset of an OSPFv3 > implementation > without the extensions. In other words, we should be extremely > suspect of changes to basic OSPFv3 mechanisms. > > > I agree with 1 and 2. As for 3, extensions cannot be a proper subset > by definition (perhaps "superset" is intended?). While I sympathize > with the last sentence of 3, I think that being too conservative in > the possible design of the extensions will constrain the achievable > performance. I would rather state that "For the MANET extensions, > departures from basic OSPFv3 mechanisms should be justified by suitable > performance benefits." I guess this is where the "as much as possible" comes in. It would be nice if it looks like a single protocol with an extension for MANET rather than two protocols that have been munged together. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 14:08:10 2004 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 OAA24909 for ; Fri, 16 Jan 2004 14:08: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 <2.00CA7959@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 14:08:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68306880 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 14:08:00 -0500 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 14:08:00 -0500 Received: from user-2ivfka0.dialup.mindspring.com ([165.247.209.64] helo=erg.sri.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AhZK3-0001mE-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 11:07:59 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <4007F9F4.8060901@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4008368D.4050901@erg.sri.com> Date: Fri, 16 Jan 2004 11:07:57 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > I believe that for the foreseeable future the vast majority of > networks will be fixed (although they may support wireless hosts). > Based on this belief and the fact that what is being proposed for > MANET is very different from base OSPFv3 I'd like to propose the > following design points for the work: > > 1. A fixed network OSPFv3 implementation shouldn't require > changes to fully interoperate with an OSPFv3 implementation > supporting the MANET extensions. > 2. The MANET extensions should be limited to wireless interfaces (or > whatever level of segregation we end up with). > 3. As much as possible, an OSPFv3 implementation with the MANET > extensions should be a proper subset of an OSPFv3 implementation > without the extensions. In other words, we should be extremely > suspect of changes to basic OSPFv3 mechanisms. I agree with Acee and Thomas regarding points 1 and 2, and I agree with Thomas regarding point 3. The extension should include all mechanisms of OSPFv3, but some of the mechanisms must be modified to support multi-hop (ad hoc) wireless interfaces. I agree that OSPFv3 mechanisms should be changed only when necessary, or if the change results in a substantial improvement in performance. The main need is to support the multi-hop wireless interface type, whether or not the routers are mobile. Since OSPF already supports topology changes, this will also support mobile routers, although some additional changes may be needed to do this more efficiently. I think it is good to support mobile routers, since these can exist in vehicle networks, robot networks, military networks, etc. I think the extensions that I proposed draft-ogier-manet-ospf-extension-00.txt satisfy points 1 and 2, and also minimize the changes to OSPF. This may also be true for the other proposal draft-spagnolo-manet-ospf-wireless-interface-00 but as I discussed previously, the latter proposal has more changes than are necessary. In particular, my proposal allows an OSPF area to include both non-MANET routers running unmodified OSPFv3, and MANET routers running the extended OSPF. A router with no MANET interface runs unmodified OSPFv3, but can have a neighbor that runs the extended OSPF. The main extension that is needed to support MANET interfaces is to generalize the concept of a Designated Router to support multi-hop wireless networks. As I have discussed, a simple and natural extension is to use a connected dominating set (CDS). Each node of the CDS is a generalized DR (called "overlapping relay" in Fred Baker's presentation). An adjacency would then be formed only between CDS nodes and their neighbors. In addition, as I have stated (see my message of January 6), it is possible to suppress ACKs for LSAs that are updated frequently, to reduce overhead when topology changes are frequent. This is a very simple modification to OSPFv3, and in fact, since ACKs can be delayed anyway, it might not require any change to the spec. I also proposed a more efficient mechanism for reliable flooding, based on periodic Database Description packets, but whether such a change is justified depends on the network parameters (mobility, bandwidth, etc) that we want to support. Richard > > > Thanks, > -- > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 14:28:22 2004 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 OAA25700 for ; Fri, 16 Jan 2004 14:28:21 -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.00CA7871@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 14:28:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68307679 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 14:28:13 -0500 Received: from 130.76.32.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 14:28:13 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA12632 for ; Fri, 16 Jan 2004 11:28:13 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id LAA10080 for ; Fri, 16 Jan 2004 11:28:12 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i0GJRGK10149 for ; Fri, 16 Jan 2004 11:27:16 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Fri, 16 Jan 2004 11:23:58 -0800 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: Proposal for OSPF MANET Extensions Design Points Thread-Index: AcPcXtVp98fcNZMXSHy3PuN5/myq9wABGzgg X-OriginalArrivalTime: 16 Jan 2004 19:23:58.0112 (UTC) FILETIME=[49E67200:01C3DC66] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B60B5@xch-nw-27.nw.nos.boeing.com> Date: Fri, 16 Jan 2004 11:23:57 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Acee, >=20 > I guess this is where the "as much as possible" comes in. It would be > nice if it looks like a single protocol with an extension for=20 > MANET rather > than two protocols that have been munged together. >=20 Well, it is possible to do nothing at all, if one is dead-set against mechanism changes-- that is why I am suggesting that proposals be considered also on the merits of their performance benefits, because at least some mechanisms will need to be modified, otherwise we wouldn't really need the extensions and could tweak timers, etc. Tom From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 15:00:19 2004 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 PAA26833 for ; Fri, 16 Jan 2004 15:00:18 -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.00CA7B4A@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 15:00:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68312457 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 15:00:16 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 15:00:16 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 168DC37CB4A for ; Fri, 16 Jan 2004 12:00:16 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19392-10 for ; Fri, 16 Jan 2004 12:00:15 -0800 (PST) Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 1CD2537CB48 for ; Fri, 16 Jan 2004 12:00:15 -0800 (PST) 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <4008431B.8010302@redback.com> Date: Fri, 16 Jan 2004 15:01:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit At the last IETF, the tunnel adjacency draft was presented and we agreed to take the discussion to the list as to whether or not it is an item OSPF WG should pursue. We've also discussed a subset proposal that only addresses the requirement of allowing a single interface to be configured in multiple OSPF areas between ABRs (Pat Murphy's initial requirement). Comments? > Folks, > > A new version of TA has been published > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunnel-adjacency-01.txt > > > There was some concerns regarding the recursive TA, discussed during the > last ietf meeting. We had some discussion with Acee and we decided that > the best way to prevent recursive TA is to allow only backbone to be the > transit area. > > This still honor what TA was initially designed for, namely > > 1) Use Backbone area as high speed path for non-backbone area ( > Intra-area / Inter-area preference ) > 2) Use automatic partition repair for non-backbone area when > summarization is performed > 3) Use TA for multiple non-backbone area path and prevent the cost of > adding additional link ( e.g. Hub and Spoke topology) > > This change will prevent TA to be used for backbone partition repair > however there is already a solution for this i.e. VL and having a > redundant solution is not required. > > > Comments are welcome, > > Sina -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 15:55:05 2004 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 PAA28673 for ; Fri, 16 Jan 2004 15:55:02 -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 <12.00CA7AD2@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 15:54:57 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68316307 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 15:54:54 -0500 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 15:54:54 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA21202 for ; Fri, 16 Jan 2004 14:54:54 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id MAA08048 for ; Fri, 16 Jan 2004 12:54:52 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i0GKren13452 for ; Fri, 16 Jan 2004 14:53:40 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Fri, 16 Jan 2004 12:53:39 -0800 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: Proposal for OSPF MANET Extensions Design Points Thread-Index: AcPcZDh4I21aGddhQ5qaw0m4cR96qgAAviEg X-OriginalArrivalTime: 16 Jan 2004 20:53:39.0454 (UTC) FILETIME=[D16E11E0:01C3DC72] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B60B8@xch-nw-27.nw.nos.boeing.com> Date: Fri, 16 Jan 2004 12:53:39 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Richard, > -----Original Message----- > From: Richard Ogier [mailto:ogier@ERG.SRI.COM] > Sent: Friday, January 16, 2004 11:08 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Proposal for OSPF MANET Extensions Design Points >=20 >=20 > Acee Lindem wrote: >=20 > > I believe that for the foreseeable future the vast majority of > > networks will be fixed (although they may support wireless hosts). > > Based on this belief and the fact that what is being proposed for > > MANET is very different from base OSPFv3 I'd like to propose the > > following design points for the work: > > > > 1. A fixed network OSPFv3 implementation shouldn't require > > changes to fully interoperate with an OSPFv3 implementation > > supporting the MANET extensions. > > 2. The MANET extensions should be limited to wireless=20 > interfaces (or > > whatever level of segregation we end up with). > > 3. As much as possible, an OSPFv3 implementation with the MANET > > extensions should be a proper subset of an OSPFv3=20 > implementation > > without the extensions. In other words, we should be extremely > > suspect of changes to basic OSPFv3 mechanisms. >=20 >=20 >=20 > I agree with Acee and Thomas regarding points 1 and 2, > and I agree with Thomas regarding point 3. > The extension should include all mechanisms of OSPFv3, > but some of the mechanisms must be modified to > support multi-hop (ad hoc) wireless interfaces. > I agree that OSPFv3 mechanisms should be changed only > when necessary, or if the change results in a substantial > improvement in performance. >=20 > The main need is to support the multi-hop wireless interface type, > whether or not the routers are mobile. > Since OSPF already supports topology changes, this will also > support mobile routers, although some additional changes may > be needed to do this more efficiently. > I think it is good to support mobile routers, since these can exist > in vehicle networks, robot networks, military networks, etc. >=20 > I think the extensions that I proposed > draft-ogier-manet-ospf-extension-00.txt > satisfy points 1 and 2, and also minimize the changes to OSPF. > This may also be true for the other proposal > draft-spagnolo-manet-ospf-wireless-interface-00 Our proposal also satisfies 1 and 2. > but as I discussed previously, the latter proposal has more > changes than are necessary. If this is indeed borne out, then I would support an alternative that performed as well or better with fewer changes to OSPF. I think it remains to be seen whether your I-D results in a design with more or fewer changes. As I've said, it's worth studying as an alternative approach (we and, I hope, others are=20 looking at it more closely), and I think that the ideas=20 are promising, but it is not yet a complete proposal IMO.=20 Tom=20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 16 18:16:15 2004 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 SAA04069 for ; Fri, 16 Jan 2004 18:16:09 -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.00CA7E34@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 18:16:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68329497 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 18:16:04 -0500 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 18:16:04 -0500 Received: from user-38ldv9g.dialup.mindspring.com ([209.86.253.48] helo=erg.sri.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AhdC7-0004mH-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 15:16:03 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <6938661A6EDA8A4EA8D1419BCE46F24C026B60B8@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <400870B0.8010505@erg.sri.com> Date: Fri, 16 Jan 2004 15:16:00 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom, >> >> >>I think the extensions that I proposed >> draft-ogier-manet-ospf-extension-00.txt >>satisfy points 1 and 2, and also minimize the changes to OSPF. >>This may also be true for the other proposal >> draft-spagnolo-manet-ospf-wireless-interface-00 >> > >Our proposal also satisfies 1 and 2. > >>but as I discussed previously, the latter proposal has more >>changes than are necessary. >> > >If this is indeed borne out, then I would support an alternative >that performed as well or better with fewer changes to OSPF. >I think it remains to be seen whether your I-D results in >a design with more or fewer changes. As I've said, it's worth >studying as an alternative approach (we and, I hope, others are >looking at it more closely), and I think that the ideas >are promising, but it is not yet a complete proposal IMO. > It is *certainly* not a complete proposal, as the draft states and I have stated. It is an informal proposal that discusses and recommends a few alternative approaches. For example, it recommends using a CDS, but does not say exactly how the CDS nodes are selected (not to mention the backup CDS nodes). I think we need to discuss design issues/choices before specifying a complete solution in detail. I'm glad you are considering some of the ideas from my draft. That's what it is for, since I don't plan to turn it into a complete spec by myself. I plan to update the draft in the next few weeks, to focus more on a single approach and to provide some more details. I look forward to seeing other proposed solutions (e.g., from Fred Baker) and to discussing the different solutions that are proposed. Richard > > >Tom > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 19 00:35:29 2004 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 AAA17776 for ; Mon, 19 Jan 2004 00:35:27 -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 <11.00CAAD06@cherry.ease.lsoft.com>; Mon, 19 Jan 2004 0:35:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68570152 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Jan 2004 00:35:21 -0500 Received: from 67.100.73.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jan 2004 00:35:21 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Proposal for OSPF MANET Extensions Design Points Thread-Index: AcPcWstk2KQAuO1FTbGQ6KBZ6gz7EQCDsaDQ Message-ID: Date: Sun, 18 Jan 2004 21:35:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I agree with Acee here and on the 3 points.=20 Venkata, isn't the reason we are trying to use OSPF because its deployed = and well understood? We could have used OLSR/TBRPF or something similar = otherwise. Cheers, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Friday, January 16, 2004 8:01 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Proposal for OSPF MANET Extensions Design Points Hi Venkata, ----- Original Message ----- From: "Naidu, Venkata" To: Sent: Friday, January 16, 2004 11:59 AM Subject: Re: Proposal for OSPF MANET Extensions Design Points > Hi Acee, > > Your proposal is reasonable. > > -> I believe that for the foreseeable future the vast majority of > -> networks will be fixed (although they may support wireless hosts). > -> Based on this belief and the fact that what is being proposed for > -> MANET is very different from base OSPFv3 I'd like to propose the > -> following design points for the work: > -> > -> 1. A fixed network OSPFv3 implementation shouldn't require > -> changes to fully interoperate with an OSPFv3 implementation > -> supporting the MANET extensions. > -> 2. The MANET extensions should be limited to wireless > -> interfaces (or > -> whatever level of segregation we end up with). > -> 3. As much as possible, an OSPFv3 implementation with the MANET > -> extensions should be a proper subset of an OSPFv3 > -> implementation > -> without the extensions. In other words, we should be = extremely > -> suspect of changes to basic OSPFv3 mechanisms. > > I don't know whether my proposal has already been suggested. > Here it is: If OSPFv3 changes to support MANET is so harmful > for existing fixed OSPFv3 operation. And if MANET thinks that > OSPF is a suitable protocol for their requirements, then it > will be a good idea to start OSPFv4 targeted only to support > IPv6 MANET requirements. > > In such a case, OSPFv4 will satisfy all the above design > requirements proposed by you. Everybody will be happy. > What is your opinion ? I'm not convinced we need a new protocol at this point. There are a number of disadvantages of a new protocol including 1) Migration of fixed networks in environments containing both MANET and fixed nodes 2) Dual protocol maintenance for new features (standards, development, deployment). > > Venkata. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 =20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 19 19:45:47 2004 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 TAA20439 for ; Mon, 19 Jan 2004 19:45: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 <10.00CAC070@cherry.ease.lsoft.com>; Mon, 19 Jan 2004 19:45:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68692649 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Jan 2004 19:45:46 -0500 Received: from 132.151.6.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jan 2004 19:35:46 -0500 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1Aijkd-0007iX-DG; Mon, 19 Jan 2004 19:28:15 -0500 X-test-idtracker: no Message-ID: Date: Mon, 19 Jan 2004 19:28:15 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Last Call: 'Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs' to Proposed Standard 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: - 'Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-2547-dnbit-03.txt From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 20 07:56:27 2004 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 HAA26963 for ; Tue, 20 Jan 2004 07:56:21 -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.00CACDC9@cherry.ease.lsoft.com>; Tue, 20 Jan 2004 7:56:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68774471 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jan 2004 07:56:14 -0500 Received: from 144.254.74.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jan 2004 07:46:14 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 20 Jan 2004 13:46:57 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0KCjpB9005896; Tue, 20 Jan 2004 13:45:52 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 Jan 2004 12:46:11 +0000 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: RE: Last Call for draft-ietf-tewg-diff-te-proto-05.txt Thread-Index: AcPfU1MQ3Nzt9PdCT9KXxXv+uleoJw== X-OriginalArrivalTime: 20 Jan 2004 12:46:11.0937 (UTC) FILETIME=[62342510:01C3DF53] Message-ID: Date: Tue, 20 Jan 2004 12:46:10 -0000 Reply-To: Mailing List Sender: Mailing List From: "Francois Le Faucheur (flefauch)" Subject: Re: Last Call for draft-ietf-tewg-diff-te-proto-05.txt Comments: cc: Ed Kern , Jim Boyle , "Wijnen, Bert (Bert)" To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hello, This is just an FYI. Last October, a Last Call was sent to TEWG, MPLS, ISIS and OSPF on . The document was then progressed to IESG Review. As part of the IESG Review, it was pointed out that the description of "Bandwidth Constraints" sub-TLV (within the "Link TLV" of the Traffic Engineering LSA) did not properly reflect the ususal 32-bit alignment. Accordingly, the description of the sub-TLV has been updated to explicitely include a "Reserved" field for 32-bit alignment. The updated description can be found in the latest version of the document i.e. which addresses all the IESG Review comments (just posted so it may take a day or so before it is visible on the IETF server). Cheers Francois >> -----Original Message----- >> From: Ed Kern [mailto:ejk@tech.org]=20 >> Sent: vendredi 3 octobre 2003 21:10 >> To: mpls@UU.NET >> Subject: Last Call for draft-ietf-tewg-diff-te-proto-05.txt=20 >> and friends=20 >>=20 >>=20 >>=20 >> ##Note: This last call is being sent to te-wg,ISIS,OSPF,MPLS=20 >> in separate=20 >> emails to trim silly "respond-all" people and aggressive=20 >> junk filters. >>=20 >> This will serve as a last call for the standards track document >>=20 >> draft-ietf-tewg-diff-te-proto-05.txt >>=20 >> available at >>=20 and the "friends" (accompanying bandwidth control drafts) going towards=20 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 Tue Jan 20 19:41:08 2004 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 TAA03802 for ; Tue, 20 Jan 2004 19:41: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 <15.00CADD00@cherry.ease.lsoft.com>; Tue, 20 Jan 2004 19:41:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68839728 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jan 2004 19:41:05 -0500 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jan 2004 19:41:05 -0500 Received: from user-38ldv8u.dialup.mindspring.com ([209.86.253.30] helo=erg.sri.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Aj6QZ-0002Nr-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jan 2004 16:41:04 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <6938661A6EDA8A4EA8D1419BCE46F24C026B60B8@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <400DCA9F.80901@erg.sri.com> Date: Tue, 20 Jan 2004 16:41:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom, See my new comments below. Henderson, Thomas R wrote: >> >>I think the extensions that I proposed >> draft-ogier-manet-ospf-extension-00.txt >>satisfy points 1 and 2, and also minimize the changes to OSPF. >>This may also be true for the other proposal >> draft-spagnolo-manet-ospf-wireless-interface-00 >> > >Our proposal also satisfies 1 and 2. > >>but as I discussed previously, the latter proposal has more >>changes than are necessary. >> > >If this is indeed borne out, then I would support an alternative >that performed as well or better with fewer changes to OSPF. >I think it remains to be seen whether your I-D results in >a design with more or fewer changes. As I've said, it's worth >studying as an alternative approach (we and, I hope, others are >looking at it more closely), and I think that the ideas >are promising, but it is not yet a complete proposal IMO. > >Tom > I agree that a design with fewer changes to OSPF is preferable if it results in similar or better performance. Based on your positive comments regarding the idea (from Section 5 of draft-ogier-manet-ospf-extension-00.txt) of dynamically deciding when to suppress ACKs for a particular LSA based on how frequently the LSA is being updated (using an exponential moving average and hysteresis), I assume that you agree that suppressing ACKs in this manner is a good way to achieve periodic, unreliable flooding of LSAs (whether this is done for all LSAs or only for LSAs that are being updated frequently). Therefore, this supports my claim that the Link State Flood (LSF) message that you introduce in your solution is not required. In other words, before adding new message types, you should try to use existing OSPF mechanisms as much as possible. Your LSF message contains a new "flooding sequence number" to detect duplicates, but OSPF already detects duplicate LSAs using the LS sequence number. In an effort to make some progress, I would like to focus on this aspect of your solution (the LSF message) and try to reach an agreement on whether or not the LSF message is required. I can think of two other reasons why the LSF message might be needed. One of these is given in Step 2.1 in Section 13.1 of your draft, where the "default route bit" of the LSF is set to indicate a default route (to avoid flooding outside LSAs within a stub wireless network). However, as we discussed and agreed on the MANET list, the same effect can be accomplished by using an OSPF stub area as specified in Section 12.4.3.1 of RFC 2328. Another possible need for the LSF message is to perform flooding via MPRs, since an LSF is forwarded only if it was received from an MPR selector. There are two questions: 1. Do we want to use MPRs to flood LSAs? 2. If the answer is yes, then can MPR flooding of LSAs be done without using the LSF message? I am proposing that LSAs be flooding using a connected dominating set (CDS) rather than MPRs, because it is simpler and closer to OSPF: each CDS node is responsible for forwarding all LSAs, whereas each MPR would be reponsible for forwarding only a subset of LSAs which must somehow be defined. But if one still wanted to use MPRs to flood LSAs, it is possible to do so without using LSF messages, either by remembering whether a given LSA was received from an MPR selector, or by defining the set of LSAs that a given MPR is responsible for forwarding as described in my draft. (In this case, periodic, unreliable flooding can be accomplished by suppressing ACKs as mentioned above.) Richard From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 20 20:12:43 2004 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 UAA05072 for ; Tue, 20 Jan 2004 20:12:43 -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.00CADB60@cherry.ease.lsoft.com>; Tue, 20 Jan 2004 20:12:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68842788 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jan 2004 20:12:41 -0500 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jan 2004 20:12:41 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id TAA20265 for ; Tue, 20 Jan 2004 19:12:40 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id TAA27870 for ; Tue, 20 Jan 2004 19:12:40 -0600 (CST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i0L1Ban06187 for ; Tue, 20 Jan 2004 19:11:36 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 20 Jan 2004 17:11:27 -0800 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: Proposal for OSPF MANET Extensions Design Points Thread-Index: AcPft3hMxbGrchk6SJSOV6gukwMz5QAAIwXA X-OriginalArrivalTime: 21 Jan 2004 01:11:27.0116 (UTC) FILETIME=[7E86FCC0:01C3DFBB] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B60FF@xch-nw-27.nw.nos.boeing.com> Date: Tue, 20 Jan 2004 17:11:26 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Richard Ogier [mailto:ogier@ERG.SRI.COM] > Sent: Tuesday, January 20, 2004 4:41 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Proposal for OSPF MANET Extensions Design Points >=20 >=20 > I agree that a design with fewer changes to OSPF is preferable if > it results in similar or better performance. >=20 > Based on your positive comments regarding the idea > (from Section 5 of draft-ogier-manet-ospf-extension-00.txt) > of dynamically deciding when to suppress ACKs for a particular > LSA based on how frequently the LSA is being updated > (using an exponential moving average and hysteresis), > I assume that you agree that suppressing ACKs in > this manner is a good way to achieve periodic, unreliable > flooding of LSAs (whether this is done for all LSAs or only > for LSAs that are being updated frequently). >=20 > Therefore, this supports my claim that the Link State Flood > (LSF) message that you introduce in your solution is not > required. =20 "I think it is a promising idea" !=3D "I agree that it is better". We're presently studying this specific issue more carefully to understand exactly how and how well it might work. Are you not doing the same, or have you already convinced yourself? Do you intend to prepare a more complete proposal on how the timers are adjusted? > In other words, before adding new message types, > you should try to use existing OSPF mechanisms as much > as possible. Your LSF message contains a new "flooding > sequence number" to detect duplicates, but OSPF already > detects duplicate LSAs using the LS sequence number. The LS sequence number is not sufficient to prevent=20 multi-hop broadcast messages from recirculating. They are=20 tied to the LSAs. LSF sequence numbers are tied to the=20 originator's IP address. >=20 > In an effort to make some progress, I would like to > focus on this aspect of your solution (the LSF message) > and try to reach an agreement on whether or not > the LSF message is required. >=20 > I can think of two other reasons why the LSF message might > be needed. One of these is given in Step 2.1 in Section 13.1 > of your draft, where the "default route bit" of the LSF > is set to indicate a default route (to avoid flooding > outside LSAs within a stub wireless network). > However, as we discussed and agreed on the MANET list, > the same effect can be accomplished by using an OSPF stub area > as specified in Section 12.4.3.1 of RFC 2328. >=20 > Another possible need for the LSF message is to perform flooding > via MPRs, since an LSF is forwarded only if it was received from > an MPR selector. There are two questions: >=20 > 1. Do we want to use MPRs to flood LSAs? > 2. If the answer is yes, then can MPR flooding of LSAs > be done without using the LSF message? >=20 > I am proposing that LSAs be flooding using a connected > dominating set (CDS) rather than MPRs, because it is simpler > and closer to OSPF: each CDS node is responsible for > forwarding all LSAs, whereas each MPR would be reponsible for > forwarding only a subset of LSAs which must somehow be defined. >=20 I agree that CDS is an alternative to MPRs. As Philippe pointed out previously, MPRs are related to CDS. If CDS provides a cleaner complete implementation, then I would be for it. I haven't seen the complete picture yet, though. Tom From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 21 00:44:22 2004 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 AAA11376 for ; Wed, 21 Jan 2004 00:44:20 -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 <12.00CAE50E@cherry.ease.lsoft.com>; Wed, 21 Jan 2004 0:44:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68874436 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jan 2004 00:44:15 -0500 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jan 2004 00:44:14 -0500 Received: from user-38ldt16.dialup.mindspring.com ([209.86.244.38] helo=erg.sri.com) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AjB9w-0005QI-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jan 2004 21:44:13 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <6938661A6EDA8A4EA8D1419BCE46F24C026B60FF@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <400E11AC.8010604@erg.sri.com> Date: Tue, 20 Jan 2004 21:44:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom, Henderson, Thomas R wrote: >>-----Original Message----- >>From: Richard Ogier [mailto:ogier@ERG.SRI.COM] >>Sent: Tuesday, January 20, 2004 4:41 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Proposal for OSPF MANET Extensions Design Points >> >> >>I agree that a design with fewer changes to OSPF is preferable if >>it results in similar or better performance. >> >>Based on your positive comments regarding the idea >>(from Section 5 of draft-ogier-manet-ospf-extension-00.txt) >>of dynamically deciding when to suppress ACKs for a particular >>LSA based on how frequently the LSA is being updated >>(using an exponential moving average and hysteresis), >>I assume that you agree that suppressing ACKs in >>this manner is a good way to achieve periodic, unreliable >>flooding of LSAs (whether this is done for all LSAs or only >>for LSAs that are being updated frequently). >> >>Therefore, this supports my claim that the Link State Flood >>(LSF) message that you introduce in your solution is not >>required. >> > >"I think it is a promising idea" != "I agree that it is better". >We're presently studying this specific issue more carefully >to understand exactly how and how well it might work. >Are you not doing the same, or have you already convinced >yourself? > I'm glad you are studying this issue. I have studied it sufficiently to convince myself there is no need to introduce a new message type. Once you convince yourself that OSPF will perform periodic, unreliable flooding if ACKs are suppressed, it is not difficult to see that LSF messages are not needed (after considering the other points in my message) and are not likely to improve performance very much. I have no reason to consider adding a new message type unless there is reason to believe it will improve performance significantly, and I see no reason why it would improve performance significantly. Can you give me such a reason? Since we are trying to minimize changes to OSPF, I guess the burden of proof is on the person proposing to change OSPF (assuming that the change is not really necessary but might improve performance). >Do you intend to prepare a more complete proposal >on how the timers are adjusted? > Yes, but you are welcome to do this too. It is fairly straightforward (based on exponential moving averages) but there are some alternative design choices. For example, RFC 2328 (A.3.5) says that retransmitted LSAs are always unicast to each neighbor that did not ACK, but in a MANET it is probably better to multicast retransmitted LSAs to all neighbors if several neighbors did not ACK. If we come up with the same design, that would be fine. Otherwise, it will be nice to have alternative designs to compare and eventually merge into a single design. >>In other words, before adding new message types, >>you should try to use existing OSPF mechanisms as much >>as possible. Your LSF message contains a new "flooding >>sequence number" to detect duplicates, but OSPF already >>detects duplicate LSAs using the LS sequence number. >> > >The LS sequence number is not sufficient to prevent >multi-hop broadcast messages from recirculating. They are >tied to the LSAs. LSF sequence numbers are tied to the >originator's IP address. > But each LSA contains the LS sequence number *and* the advertising router (originator). Can you explain or give an example to show that the LS sequence number is not sufficient to prevent LSAs from recirculating? I am really just talking about the way OSPF already does flooding, so this should not be a problem. I guess you are talking about your flooding mechanism using the LSF message, but my point is that LSF messages are not needed. Richard >In an effort to make some progress, I would like to >focus on this aspect of your solution (the LSF message) >and try to reach an agreement on whether or not >the LSF message is required. > >I can think of two other reasons why the LSF message might >be needed. One of these is given in Step 2.1 in Section 13.1 >of your draft, where the "default route bit" of the LSF >is set to indicate a default route (to avoid flooding >outside LSAs within a stub wireless network). >However, as we discussed and agreed on the MANET list, >the same effect can be accomplished by using an OSPF stub area >as specified in Section 12.4.3.1 of RFC 2328. > >Another possible need for the LSF message is to perform flooding >via MPRs, since an LSF is forwarded only if it was received from >an MPR selector. There are two questions: > >1. Do we want to use MPRs to flood LSAs? >2. If the answer is yes, then can MPR flooding of LSAs > be done without using the LSF message? > >I am proposing that LSAs be flooding using a connected >dominating set (CDS) rather than MPRs, because it is simpler >and closer to OSPF: each CDS node is responsible for >forwarding all LSAs, whereas each MPR would be reponsible for >forwarding only a subset of LSAs which must somehow be defined. > I agree that CDS is an alternative to MPRs. As Philippe pointed out previously, MPRs are related to CDS. If CDS provides a cleaner complete implementation, then I would be for it. I haven't seen the complete picture yet, though. Tom From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 21 12:11:19 2004 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 MAA00471 for ; Wed, 21 Jan 2004 12:11:19 -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 <16.00CAF14F@cherry.ease.lsoft.com>; Wed, 21 Jan 2004 12:11:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68944492 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jan 2004 12:11:16 -0500 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jan 2004 12:11:16 -0500 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA07493 for ; Wed, 21 Jan 2004 09:11:04 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id JAA11464 for ; Wed, 21 Jan 2004 09:11:13 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i0LHAXQ18785 for ; Wed, 21 Jan 2004 09:10:33 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 21 Jan 2004 09:08:57 -0800 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: Proposal for OSPF MANET Extensions Design Points Thread-Index: AcPf4d/IBJumiog9RgChEW5J7tdS2wAXWvKw X-OriginalArrivalTime: 21 Jan 2004 17:08:57.0456 (UTC) FILETIME=[41992F00:01C3E041] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B6101@xch-nw-27.nw.nos.boeing.com> Date: Wed, 21 Jan 2004 09:08:57 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Richard Ogier [mailto:ogier@ERG.SRI.COM] > Sent: Tuesday, January 20, 2004 9:44 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Proposal for OSPF MANET Extensions Design Points >=20 >=20 > >>In other words, before adding new message types, > >>you should try to use existing OSPF mechanisms as much > >>as possible. Your LSF message contains a new "flooding > >>sequence number" to detect duplicates, but OSPF already > >>detects duplicate LSAs using the LS sequence number. > >> > > > >The LS sequence number is not sufficient to prevent > >multi-hop broadcast messages from recirculating. They are > >tied to the LSAs. LSF sequence numbers are tied to the > >originator's IP address. > > > But each LSA contains the LS sequence number *and* the=20 > advertising router > (originator). Can you explain or give an example to show that the LS > sequence > number is not sufficient to prevent LSAs from recirculating? I am > really just talking > about the way OSPF already does flooding, so this should not=20 > be a problem. > I guess you are talking about your flooding mechanism using=20 > the LSF message, > but my point is that LSF messages are not needed. >=20 If LSAs are broadcast periodically, and unacknowledged, then a node may have to forward the identical LSA again (to send it downstream to a node that may not have received it successfully the first time). It cannot tell by inspection of the normal LSU (without sequence number) whether this is a new LSU to be forwarded or an instance of one that it has already forwarded. If dissemination is reliable, then LSF is not needed. The premise of OLSR was that periodic unreliable dissemination was more transmission efficient than reliable dissemination with acking (at a certain mobility point, the performance benefits transition from reliable to unreliable flooding). In looking at how OSPFv2 behaves with or without the wireless interface type, we have observed this behavior. It would be nice if we had a hybrid mode of operation to account for both stable and rapidly varying networks-- that is why the mechanism you sketched out in sec. 5 of your draft is appealing. But we would like to make sure that there are no unanticipated downsides to that mechanism before jumping on board with it. Tom From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 21 13:09:35 2004 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 NAA02120 for ; Wed, 21 Jan 2004 13:09: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 <8.00CAF1AA@cherry.ease.lsoft.com>; Wed, 21 Jan 2004 13:09:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68954055 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jan 2004 13:09:24 -0500 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jan 2004 13:09:24 -0500 Received: from user-38ldtbd.dialup.mindspring.com ([209.86.245.109] helo=erg.sri.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AjMn5-0006Hv-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jan 2004 10:09:23 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <6938661A6EDA8A4EA8D1419BCE46F24C026B6101@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <400EC052.2090705@erg.sri.com> Date: Wed, 21 Jan 2004 10:09:22 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom, Henderson, Thomas R wrote: >>-----Original Message----- >>From: Richard Ogier [mailto:ogier@ERG.SRI.COM] >>Sent: Tuesday, January 20, 2004 9:44 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Proposal for OSPF MANET Extensions Design Points >> >> >>>>In other words, before adding new message types, >>>>you should try to use existing OSPF mechanisms as much >>>>as possible. Your LSF message contains a new "flooding >>>>sequence number" to detect duplicates, but OSPF already >>>>detects duplicate LSAs using the LS sequence number. >>>> >>>The LS sequence number is not sufficient to prevent >>>multi-hop broadcast messages from recirculating. They are >>>tied to the LSAs. LSF sequence numbers are tied to the >>>originator's IP address. >>> >>But each LSA contains the LS sequence number *and* the >>advertising router >>(originator). Can you explain or give an example to show that the LS >>sequence >>number is not sufficient to prevent LSAs from recirculating? I am >>really just talking >>about the way OSPF already does flooding, so this should not >>be a problem. >>I guess you are talking about your flooding mechanism using >>the LSF message, >>but my point is that LSF messages are not needed. >> >If LSAs are broadcast periodically, and unacknowledged, then a node >may have to forward the identical LSA again (to send it downstream >to a node that may not have received it successfully the first time). >It cannot tell by inspection of the normal LSU (without sequence >number) whether this is a new LSU to be forwarded or an instance >of one that it has already forwarded. > The LSU just carries LSAs one hop further from the originator. OSPF inspects the LSA (with sequence number) to determine if it is a duplicate. Again, I am really just talking about how OSPF already floods LSAs, with some minor modifications (but without requiring the new LSF packet type). In OSPF, a router retransmits an LSA (to neighbors) after RxmtInterval if no ACK is received. This is the basis of the idea I sketched in Section 5 of my draft (which also discusses how a router decides when to suppress ACKs). The point I am making is that the LSF message is not required in order to achieve periodic, unreliable flooding. (Whether it improves performance is another question that can be studied.) And the reason is that OSPF correctly performs periodic, unreliable flooding (although not in the same manner as your method with LSF messages) if ACKs are supressed. > > >If dissemination is reliable, then LSF is not needed. > My point is that LSF is not needed even if unreliable flooding is used, as discussed above. >The premise >of OLSR was that periodic unreliable dissemination was more transmission >efficient than reliable dissemination with acking (at a certain >mobility point, the performance benefits transition from reliable >to unreliable flooding). In looking at how OSPFv2 behaves with or >without the wireless interface type, we have observed this behavior. >It would be nice if we had a hybrid mode of operation to account for >both stable and rapidly varying networks-- that is why the mechanism >you sketched out in sec. 5 of your draft is appealing. But we would >like to make sure that there are no unanticipated downsides to that >mechanism before jumping on board with it. > I completely agree that it needs to be studied further to make sure there are no unexpected downsides. But the only point I am trying to make now is that the LSF message is not *required* in order to achieve periodic, unreliable flooding of LSAs. Richard > > >Tom > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 21 14:18:08 2004 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 OAA03997 for ; Wed, 21 Jan 2004 14:18: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 <19.00CAF2D5@cherry.ease.lsoft.com>; Wed, 21 Jan 2004 14:18:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68960203 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jan 2004 14:17:57 -0500 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jan 2004 14:17:57 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA05933 for ; Wed, 21 Jan 2004 13:17:56 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id NAA20300 for ; Wed, 21 Jan 2004 13:17:55 -0600 (CST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i0LJH8Q17162 for ; Wed, 21 Jan 2004 11:17:09 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 21 Jan 2004 11:16:47 -0800 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: Proposal for OSPF MANET Extensions Design Points Thread-Index: AcPgSf58RrqKMVU/Si2fLc6G3/kDcgABoJ3A X-OriginalArrivalTime: 21 Jan 2004 19:16:47.0269 (UTC) FILETIME=[1D29C550:01C3E053] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B6109@xch-nw-27.nw.nos.boeing.com> Date: Wed, 21 Jan 2004 11:16:34 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Richard Ogier [mailto:ogier@ERG.SRI.COM] > Sent: Wednesday, January 21, 2004 10:09 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Proposal for OSPF MANET Extensions Design Points >=20 >=20 > Tom, >=20 > Henderson, Thomas R wrote: >=20 > >>-----Original Message----- > >>From: Richard Ogier [mailto:ogier@ERG.SRI.COM] > >>Sent: Tuesday, January 20, 2004 9:44 PM > >>To: OSPF@PEACH.EASE.LSOFT.COM > >>Subject: Re: Proposal for OSPF MANET Extensions Design Points > >> > The LSU just carries LSAs one hop further from the=20 > originator. OSPF inspects > the LSA (with sequence number) to determine if it is a duplicate. > Again, I am really > just talking about how OSPF already floods LSAs, with some minor > modifications > (but without requiring the new LSF packet type). In OSPF, a router > retransmits > an LSA (to neighbors) after RxmtInterval if no ACK is=20 > received. This is > the basis > of the idea I sketched in Section 5 of my draft (which also discusses > how a router > decides when to suppress ACKs). The point I am making is that the LSF > message > is not required in order to achieve periodic, unreliable flooding. > (Whether it > improves performance is another question that can be studied.) And the > reason is > that OSPF correctly performs periodic, unreliable flooding=20 > (although not > in the > same manner as your method with LSF messages) if ACKs are supressed. >=20 OK, I agree with your argument. I was arguing from the perspective that if you have multi-hop broadcast, you need a sequence number. When using MPRs, you want to have a multi-hop broadcast dissemination, or else you=20 need to start tagging LSAs and remembering the last-hop nodes that=20 forwarded them to you (and comparing against the MPR selector lists = which may change over time) before deciding whether you are keeping them on = the retransmission list-- we found it easier to use a multi-hop broadcast = message in that case. Another reason we found the LSF useful was that it = allowed the LSA originator to control the retransmission frequency based on the=20 source of the LSA-- LSAs from outside the subnet could be retransmitted = at=20 a lower frequency to save on overhead. It also allows you to flood a=20 default without configuring it as a stub area, as you pointed out = earlier. =20 If CDS is used for efficient broadcast instead of MPR, and adopting your = proposed scheme, then LSF may no longer be needed. =20 Tom From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 22 06:28:32 2004 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 GAA16979 for ; Thu, 22 Jan 2004 06:28:29 -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.00CB0E9D@cherry.ease.lsoft.com>; Thu, 22 Jan 2004 6:28:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69088561 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 22 Jan 2004 06:28:25 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 22 Jan 2004 06:28:23 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 22 Jan 2004 16:57:27 +0530 Received: from vanitha (vanitha.future.futsoft.com [10.6.4.92]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i0MBKqU21874 for ; Thu, 22 Jan 2004 16:50:52 +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.50.4522.1200 Message-ID: <003701c3e0da$761536e0$5c04060a@future.futsoft.com> Date: Thu, 22 Jan 2004 16:55:37 +0530 Reply-To: Mailing List Sender: Mailing List From: Vanitha N Subject: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, Since TOS field is removed in OSPFv3, OSPF Area Default Metric Table is removed from OSPFv3 mib. Instead 'ospfv3StubMetric' is added to Ospfv3AreaTable. Any specific reason for not considering Metric Type field (ospfStubMetricType). This type variable is required for setting different metric type for NSSA and Stub area. Regards, Vanitha N. *************************************************************************** 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 Jan 22 09:37:10 2004 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 JAA22405 for ; Thu, 22 Jan 2004 09:37:09 -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.00CB1148@cherry.ease.lsoft.com>; Thu, 22 Jan 2004 9:37:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69099690 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 22 Jan 2004 09:37:07 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 22 Jan 2004 09:37:07 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F24B567494E for ; Thu, 22 Jan 2004 06:37:06 -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 14326-05 for ; Thu, 22 Jan 2004 06:37:06 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.28]) by prattle.redback.com (Postfix) with SMTP id 44D7867494A for ; Thu, 22 Jan 2004 06:37:06 -0800 (PST) References: <003701c3e0da$761536e0$5c04060a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <08c501c3e0f5$346799c0$0302a8c0@aceeinspiron> Date: Thu, 22 Jan 2004 09:37:04 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vanitha, Sounds like it would be reasonable to add ospfv3StubMetricType similar to ospfStubMetricType. Vishwas - how does this sound? Thanks, Acee ----- Original Message ----- From: "Vanitha N" To: Sent: Thursday, January 22, 2004 6:25 AM Subject: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt > Hi, > Since TOS field is removed in OSPFv3, OSPF Area Default Metric Table is > removed from OSPFv3 mib. Instead 'ospfv3StubMetric' is added to > Ospfv3AreaTable. Any specific reason for not considering Metric Type field > (ospfStubMetricType). This type variable is required for setting different > metric type for NSSA and Stub area. > > Regards, > Vanitha N. > > > > > > *************************************************************************** > 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 Jan 23 00:27:25 2004 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 AAA29553 for ; Fri, 23 Jan 2004 00:27:18 -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 <15.00CB26F0@cherry.ease.lsoft.com>; Fri, 23 Jan 2004 0:26:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69193627 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 23 Jan 2004 00:26:48 -0500 Received: from 67.100.73.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 Jan 2004 00:26:48 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt Thread-Index: AcPg9Tg3mnbwUqPvTPKzljzfBY7cmAAmLuWg Message-ID: Date: Thu, 22 Jan 2004 21:26:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee/Vanitha, It sounds reasonable. I will add the following: - ospfv3AreaStubMetricType -> ospfv3AreaStubMetricType OBJECT-TYPE=20 SYNTAX INTEGER {=20 ospfv3Metric (1), -- OSPF Metric=20 comparableCost (2), -- external type 1=20 nonComparable (3) -- external type 2=20 }=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "This variable displays the type of metric ad-=20 vertised as a default route."=20 DEFVAL { ospfv3Metric }=20 ::=3D { ospfv3AreaEntry 15 } Besides changing the names=20 ospfv3SpfRuns =3D>> ospfv3AreaSpfRuns and=20 ospfv3StubMetric =3D>> ospfv3AreaStubMetric Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Thursday, January 22, 2004 4:37 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt Vanitha, Sounds like it would be reasonable to add ospfv3StubMetricType similar to ospfStubMetricType. Vishwas - how does this sound? Thanks, Acee ----- Original Message ----- From: "Vanitha N" To: Sent: Thursday, January 22, 2004 6:25 AM Subject: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt > Hi, > Since TOS field is removed in OSPFv3, OSPF Area Default Metric = Table is > removed from OSPFv3 mib. Instead 'ospfv3StubMetric' is added to > Ospfv3AreaTable. Any specific reason for not considering Metric Type = field > (ospfStubMetricType). This type variable is required for setting = different > metric type for NSSA and Stub area. > > Regards, > Vanitha N. > > > > > > = *************************************************************************= ** > 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. > = *************************************************************************= ** --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 =20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 23 00:34:14 2004 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 AAA29855 for ; Fri, 23 Jan 2004 00:34:12 -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.00CB25D2@cherry.ease.lsoft.com>; Fri, 23 Jan 2004 0:34:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69194941 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 23 Jan 2004 00:34:09 -0500 Received: from 67.100.73.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 Jan 2004 00:34:09 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt Thread-Index: AcPg9Tg3mnbwUqPvTPKzljzfBY7cmAAmLuWgAACIc2A= Message-ID: Date: Thu, 22 Jan 2004 21:34:08 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Stub Metric Type in MIB draft-ietf-ospf-mib-update-08.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Besides for ospfStubAreaEntry the DESCRIPTION would need to be updated = too. Thanks, Vishwas -----Original Message----- From: Vishwas Manral=20 Sent: Friday, January 23, 2004 11:00 AM To: 'Mailing List' Subject: RE: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt Hi Acee/Vanitha, It sounds reasonable. I will add the following: - ospfv3AreaStubMetricType -> ospfv3AreaStubMetricType OBJECT-TYPE=20 SYNTAX INTEGER {=20 ospfv3Metric (1), -- OSPF Metric=20 comparableCost (2), -- external type 1=20 nonComparable (3) -- external type 2=20 }=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "This variable displays the type of metric ad-=20 vertised as a default route."=20 DEFVAL { ospfv3Metric }=20 ::=3D { ospfv3AreaEntry 15 } Besides changing the names=20 ospfv3SpfRuns =3D>> ospfv3AreaSpfRuns and=20 ospfv3StubMetric =3D>> ospfv3AreaStubMetric Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Thursday, January 22, 2004 4:37 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt Vanitha, Sounds like it would be reasonable to add ospfv3StubMetricType similar to ospfStubMetricType. Vishwas - how does this sound? Thanks, Acee ----- Original Message ----- From: "Vanitha N" To: Sent: Thursday, January 22, 2004 6:25 AM Subject: Stub Metric Type in MIB draft-ietf-ospf-ospfv3-mib-07.txt > Hi, > Since TOS field is removed in OSPFv3, OSPF Area Default Metric = Table is > removed from OSPFv3 mib. Instead 'ospfv3StubMetric' is added to > Ospfv3AreaTable. Any specific reason for not considering Metric Type = field > (ospfStubMetricType). This type variable is required for setting = different > metric type for NSSA and Stub area. > > Regards, > Vanitha N. > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 =20 From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 24 11:34:49 2004 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 LAA13514 for ; Sat, 24 Jan 2004 11:34:49 -0500 (EST) Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CBA9EB@cherry.ease.lsoft.com>; Sat, 24 Jan 2004 11:34:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69340120 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 24 Jan 2004 04:34:38 -0500 Received: from 194.191.0.1 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 24 Jan 2004 04:34:38 -0500 Received: from net4u.ch (zux006-046-127.adsl.green.ch [81.6.46.127]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id i0O9YawC026872 for ; Sat, 24 Jan 2004 10:34:37 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6938661A6EDA8A4EA8D1419BCE46F24C026B60AC@xch-nw-27.nw.nos.boeing.com> <014401c3dc5e$81f41740$0302a8c0@aceeinspiron> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <401230D8.1010300@xebeo.com> Date: Sat, 24 Jan 2004 09:46:16 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: >Hi Tom, > >----- Original Message ----- >From: "Henderson, Thomas R" >To: >Sent: Friday, January 16, 2004 12:37 PM >Subject: Re: Proposal for OSPF MANET Extensions Design Points > > > > >>-----Original Message----- >>From: Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Friday, January 16, 2004 6:49 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Proposal for OSPF MANET Extensions Design Points >> >> >>I believe that for the foreseeable future the vast majority of >>networks will be fixed (although they may support wireless hosts). >>Based on this belief and the fact that what is being proposed for >>MANET is very different from base OSPFv3 I'd like to propose the >>following design points for the work: >> >> 1. A fixed network OSPFv3 implementation shouldn't require >> changes to fully interoperate with an OSPFv3 implementation >> supporting the MANET extensions. >> 2. The MANET extensions should be limited to wireless >>interfaces (or >> whatever level of segregation we end up with). >> 3. As much as possible, an OSPFv3 implementation with the MANET >> extensions should be a proper subset of an OSPFv3 >>implementation >> without the extensions. In other words, we should be extremely >> suspect of changes to basic OSPFv3 mechanisms. >> >> >>I agree with 1 and 2. As for 3, extensions cannot be a proper subset >>by definition (perhaps "superset" is intended?). While I sympathize >>with the last sentence of 3, I think that being too conservative in >>the possible design of the extensions will constrain the achievable >>performance. I would rather state that "For the MANET extensions, >>departures from basic OSPFv3 mechanisms should be justified by suitable >>performance benefits." >> >> > >I guess this is where the "as much as possible" comes in. It would be >nice if it looks like a single protocol with an extension for MANET rather >than two protocols that have been munged together. > >Thanks, >Acee > > > Here my spare change after reading the drafts hanging out to dry and having thought about the issue for a while. The hat I'm putting on is that of a vendor having a stable implementation with large deployments in the field and being interested in least painfull customer adaptation (not necessarily my current job situation but from experience the best hat to assure wide-adoption of a work like this in the field, the metric of success I perceive as the most practical one for IETF.). (i) Don't make it a separate protocol. It will duplicate the amount of code around, be close-enough to ospf to be confused with it but on the other hand not-ospf so people using ospf concepts to talk about it will end up confused by subtle differences in the way it works. This kind of confusion mirrors itself in configurations/architectures and resulting networks. And of course, spinning out a new protocols will take much, much longer than any of the parties putting forward such a proposal dare to admit it will. (ii) I think any resulting solution will change the flooding procedures in very non-trivial ways, therefore I am against an 'interface'-type. Pretty much all interface types share the flooding code in any implementation I saw and mudding with it that heavily will cause deployment problems with existing/deployed interface types. Even if the spec is clear and concise, implementing and testing flooding changes on a large scale is very risky. I would suggest that having an 'manet-area' like an nssa-area is the best solution. It leaves for existing implementations an easy option to not implement such an area type, the option to implement different flooding code based on area type (subtle but important difference from having a flooding code per interface type). An area is easily containted deployment wise (so if manet changes cause troubles, it will be area contained), it will be much easier to debug/correctly interoperate than an area with mixture of manet and non-manet interfaces since the translation on area boundary will allow to track/isolate problems caused by flooding within manet. The manet area could be done as 'some-other-area-type' like nssa-area or as superset of standard ospf area so e.g. manet area could have a completely new lsa type, rather than trying to trick manet work into existing types or heavily use opaques which one could argue is not a very elegant solution. thanks -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 25 07:37:29 2004 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 HAA00691 for ; Sun, 25 Jan 2004 07:37:28 -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 <20.00CBB9DC@cherry.ease.lsoft.com>; 25 Jan 2004 7:37:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69518566 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 25 Jan 2004 07:37:06 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 25 Jan 2004 07:37:06 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BC29E7CE608 for ; Sun, 25 Jan 2004 04:37:05 -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 15492-09 for ; Sun, 25 Jan 2004 04:37:05 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.49]) by prattle.redback.com (Postfix) with SMTP id EEAA37CE609 for ; Sun, 25 Jan 2004 04:37:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0c4d01c3e33f$eadca780$0302a8c0@aceeinspiron> Date: Sun, 25 Jan 2004 07:36:55 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Traffic Engineering Extensions to OSPF version 3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit There hasn't been much discussion this document. Has anybody implemented it? One thing I think needs to be removed or elaborated is the applicability to OSPFv2 (described how the new TLV and sub-TLV would be used in OSPFv2). Thanks, ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 27 17:35:35 2004 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 RAA27487 for ; Tue, 27 Jan 2004 17:35:34 -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 <12.00CBFCB8@cherry.ease.lsoft.com>; Tue, 27 Jan 2004 17:35:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69864392 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 Jan 2004 17:35:24 -0500 Received: from 209.119.1.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 Jan 2004 17:25:24 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.FE74C78A@wnt.dc.lsoft.com>; Tue, 27 Jan 2004 17:25:24 -0500 Message-ID: Date: Tue, 27 Jan 2004 17:25:14 -0500 Reply-To: Mailing List Sender: Mailing List From: Abhijit Kumbhare Subject: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hello, If the user has not configured anything - what is the generally accepted default preference in most implementations - should the configured default route take precedence or the learned (OSPF) default route? I believe Cisco uses the static (configured) default route over the learned default route - how do others handle it? Thanks, Abhijit Kumbhare From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 27 18:31:24 2004 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 SAA00029 for ; Tue, 27 Jan 2004 18:31:22 -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.00CBFC25@cherry.ease.lsoft.com>; Tue, 27 Jan 2004 18:31:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69870086 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 Jan 2004 18:31:10 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 Jan 2004 18:31:10 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 796264247E5 for ; Tue, 27 Jan 2004 15:31:09 -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 05642-03 for ; Tue, 27 Jan 2004 15:31:09 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.45]) by prattle.redback.com (Postfix) with SMTP id D2DD24247EA for ; Tue, 27 Jan 2004 15:31:07 -0800 (PST) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <00c401c3e52d$9f2f6bc0$0302a8c0@aceeinspiron> Date: Tue, 27 Jan 2004 18:30:57 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Abhijit Kumbhare" To: Sent: Tuesday, January 27, 2004 5:25 PM Subject: Configured default route or OSPF default route > Hello, > > If the user has not configured anything - what is the generally accepted > default preference in most implementations - should the configured default > route take precedence or the learned (OSPF) default route? > > I believe Cisco uses the static (configured) default route over the learned > default route - how do others handle it? Hi Abhijit, We, Redback, also will prefer a static route over an OSPF learned route. I think this is the right default since the static route is explicit. We do allow the preference (aka, administrative distance) to be configured for individual static routes. Additionally, we'll install the a backup OSPF external route (default or otherwise) even if we are advertising an external route ourselves and let the defaulted or configued route preferences sort themselves out in RIB. If we install an OSPF intra or inter area route, we will discontinue advertising an OSPF external route. I think this approach offers the most flexibility. Thanks, Acee > > Thanks, > Abhijit Kumbhare From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 27 18:59:27 2004 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 SAA01201 for ; Tue, 27 Jan 2004 18:59:22 -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.00CBFDB4@cherry.ease.lsoft.com>; Tue, 27 Jan 2004 18:59:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69873285 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 Jan 2004 18:59:16 -0500 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 Jan 2004 18:59:16 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA25817 for ; Tue, 27 Jan 2004 17:59:16 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id RAA01406 for ; Tue, 27 Jan 2004 17:59:14 -0600 (CST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i0RNuOb27647 for ; Tue, 27 Jan 2004 15:56:24 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 27 Jan 2004 15:44:03 -0800 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: Proposal for OSPF MANET Extensions Design Points Thread-Index: AcPimBT3t+SGt7T0TGup0wdtjRDQKQCkAyvg X-OriginalArrivalTime: 27 Jan 2004 23:44:03.0619 (UTC) FILETIME=[720D1730:01C3E52F] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC257@xch-nw-27.nw.nos.boeing.com> Date: Tue, 27 Jan 2004 15:44:04 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Proposal for OSPF MANET Extensions Design Points To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Tony Przygienda [mailto:prz@XEBEO.COM]=20 > Sent: Saturday, January 24, 2004 12:46 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Proposal for OSPF MANET Extensions Design Points >=20 > I would suggest that > having an 'manet-area' like an nssa-area is the best solution.=20 This is an interesting possibility. Although you cite some "limit the implementation impact" reasons for defining this=20 as an area, probably the most compelling argument would be the=20 opportunity to limit the flooding scope of more rapidly=20 varying LSAs, and take advantage of the opportunity to=20 summarize at the area boundary. =20 On the other hand, there are some potential drawbacks to this, most notably the inability to handle area partitioning (which=20 is very likely to occur in some scenarios), and the general=20 difficulty of configuring/maintaining static area configurations. What would be most desirable is a way to achieve the flooding scope reduction and summarization qualities of the area without=20 specifically requiring the area construct. Some ideas that have=20 been floated in this space include the Fuzzy Sighted Link State=20 and the Limited Flooding proposal=20 (draft-dovolsky-ccamp-ospf-limited-flooding-00.txt). Tom From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 28 18:33:23 2004 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 SAA07483 for ; Wed, 28 Jan 2004 18:33:21 -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.00CC1A72@cherry.ease.lsoft.com>; Wed, 28 Jan 2004 18:33:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 70020924 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 Jan 2004 18:33:12 -0500 Received: from 129.188.136.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 Jan 2004 18:23:11 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i0SNNBqC026330 for ; Wed, 28 Jan 2004 16:23:11 -0700 (MST) Received: from il06exb01.corp.mot.com (il06exb01.corp.mot.com [10.0.111.59]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i0SNN9Kp007900 for ; Wed, 28 Jan 2004 17:23:09 -0600 Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Wed, 28 Jan 2004 17:23:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Message-ID: Date: Wed, 28 Jan 2004 17:23:08 -0600 Reply-To: Mailing List Sender: Mailing List From: Bhatia Pawan-CPB101 Subject: Re: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list 3COM (and now Motorola) routers also prefer static routes over OSPF learned routes. However, there is an option to configure a static route such that the OSPF learned route takes precedence. regards, Pawan -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Tuesday, January 27, 2004 3:31 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Configured default route or OSPF default route ----- Original Message ----- From: "Abhijit Kumbhare" To: Sent: Tuesday, January 27, 2004 5:25 PM Subject: Configured default route or OSPF default route > Hello, > > If the user has not configured anything - what is the generally > accepted default preference in most implementations - should the > configured default route take precedence or the learned (OSPF) default > route? > > I believe Cisco uses the static (configured) default route over the > learned default route - how do others handle it? Hi Abhijit, We, Redback, also will prefer a static route over an OSPF learned route. I think this is the right default since the static route is explicit. We do allow the preference (aka, administrative distance) to be configured for individual static routes. Additionally, we'll install the a backup OSPF external route (default or otherwise) even if we are advertising an external route ourselves and let the defaulted or configued route preferences sort themselves out in RIB. If we install an OSPF intra or inter area route, we will discontinue advertising an OSPF external route. I think this approach offers the most flexibility. Thanks, Acee > > Thanks, > Abhijit Kumbhare From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 29 04:00:04 2004 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 EAA08707 for ; Thu, 29 Jan 2004 04:00:04 -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.00CC25AB@cherry.ease.lsoft.com>; Thu, 29 Jan 2004 4:00:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 70074453 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Jan 2004 03:59:53 -0500 Received: from 64.104.193.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 Jan 2004 03:49:53 -0500 Received: from bej-core-1.cisco.com (64.104.160.31) by syd-iport-1.cisco.com with ESMTP; 29 Jan 2004 00:57:45 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by bej-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0T8lKfI014775 for ; Thu, 29 Jan 2004 16:48:13 +0800 (CST) Received: from xbe-ams-312.cisco.com ([144.254.228.202]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 Jan 2004 08:48:21 +0000 Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 Jan 2004 09:48:18 +0100 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="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: I-D ACTION:draft-dec-ospf-tags-00.txt Thread-Index: AcPmRAkPVyOD+fULRIqDEoarA+7mAg== X-OriginalArrivalTime: 29 Jan 2004 08:48:18.0550 (UTC) FILETIME=[A451E160:01C3E644] Message-ID: <1D70B315AD50C94BB5FDB0F31BBFEE7E03366D30@xbe-ams-313.cisco.com> Date: Thu, 29 Jan 2004 09:44:33 +0100 Reply-To: Mailing List Sender: Mailing List From: "Wojciech Dec (wdec)" Subject: I-D ACTION:draft-dec-ospf-tags-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Forwarding draft announcement to OSPF discussion group. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Proposal for a Tag Value field in OSPF Author(s) : W. Dec Filename : draft-dec-ospf-tags-00.txt Pages : 11 Date : 2004-1-21 This document proposes a method for encoding in Open Shortest Path First (OSPF) Internal and External Link State Advertisements (LSA) a Tag Value field containing user tag information associated with each link or prefix described within an LSA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dec-ospf-tags-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-dec-ospf-tags-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-dec-ospf-tags-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. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 29 13:49:34 2004 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 NAA07481 for ; Thu, 29 Jan 2004 13:49:32 -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 <20.00CC2FB0@cherry.ease.lsoft.com>; Thu, 29 Jan 2004 13:49:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 70153638 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Jan 2004 13:49:23 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 Jan 2004 13:49:22 -0500 Received: from smirtoraw2k03 (dhcp-171-69-100-248.cisco.com [171.69.100.248]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i0TInGJ29765 for ; Thu, 29 Jan 2004 10:49:16 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001C_01C3E655.8DD4FBA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: <001b01c3e698$9bf83ba0$f86445ab@amer.cisco.com> Date: Thu, 29 Jan 2004 10:49:16 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: I-D ACTION:draft-mirtorabi-ospfv3-af-alt-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C3E655.8DD4FBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, A new version of address-family draft is available. The diffs are o Section 3, Instance ID range has been updated o Section 8, for IPv4 AF nexthop calculation, an IPv4 address will be advertised in "link-local address filed" of Link-LSA. Previously this address was advertised in prefix field with LA-bit set. o Section 9, adds the support of OSPFv3 over IPv4 o Section 10, VL support has been updated Thanks Sina -------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Support of address families in OSPFv3 Author(s) : S. Mirtorabi Filename : draft-mirtorabi-ospfv3-af-alt-01.txt Pages : 6 Date : 2004-1-28 This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AF's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af-alt-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-mirtorabi-ospfv3-af-alt-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-mirtorabi-ospfv3-af-alt-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_000_001C_01C3E655.8DD4FBA0 Content-Type: Message/External-body; name="ATT00129.dat" Content-Disposition: attachment; filename="ATT00129.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-29104348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mirtorabi-ospfv3-af-alt-01.txt ------=_NextPart_000_001C_01C3E655.8DD4FBA0 Content-Type: Message/External-body; name="draft-mirtorabi-ospfv3-af-alt-01.txt" Content-Disposition: attachment; filename="draft-mirtorabi-ospfv3-af-alt-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-29104348.I-D@ietf.org> ------=_NextPart_000_001C_01C3E655.8DD4FBA0-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 29 20:13:07 2004 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 UAA04069 for ; Thu, 29 Jan 2004 20:13: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 <0.00CC3CE2@cherry.ease.lsoft.com>; Thu, 29 Jan 2004 20:13:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 70201012 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Jan 2004 20:12:49 -0500 Received: from 216.174.224.194 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 Jan 2004 20:02:49 -0500 Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Thu, 29 Jan 2004 16:53:36 -0800 Received: by main.mahinetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jan 2004 17:03:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7D995F673DABE04F95CACA0E038478FF1BC7FC@main.mahinetworks.com> Date: Thu, 29 Jan 2004 17:03:37 -0800 Reply-To: Mailing List Sender: Mailing List From: Sriganesh Kini Subject: FW: I-D ACTION:draft-kini-ospf-gr-enhance-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Forwarding draft announcement to OSPF discussion group. Comments are welcome. === Sriganesh Kini -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhancements to OSPF Graceful Restart for Heterogeneous Environments Author(s) : S. Kini Filename : draft-kini-ospf-gr-enhance-00.txt Pages : 16 Date : 2004-1-23 Reliability is a fundamental concern for the network. As a solution to improve network stability, the non-stop forwarding paradigm depends on protocol recovery based on graceful restart techniques. One of the proposed graceful restart techniques for [OSPF], a widely deployed IGP, is described in [OSPF-GR]. This technique has a limitation of not being backward compatible, in the sense that if a neighbor does not support the helper mode described in [OSPF-GR], the graceful-restart procedure will fail (i.e., revert to normal restart). For large multi-vendor networks, this scenario is fairly common. In this draft, we describe techniques that can achieve OSPF graceful restart even if a neighboring router does not support the helper-mode of [OSPF-GR]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kini-ospf-gr-enhance-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-kini-ospf-gr-enhance-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-kini-ospf-gr-enhance-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. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 30 12:00:52 2004 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 MAA27992 for ; Fri, 30 Jan 2004 12:00:51 -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.00CC4F42@cherry.ease.lsoft.com>; Fri, 30 Jan 2004 12:00:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 70316183 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Jan 2004 12:00:49 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 Jan 2004 11:50:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26965; Fri, 30 Jan 2004 11:50:46 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200401301650.LAA26965@ietf.org> Date: Fri, 30 Jan 2004 11:50:46 -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-graceful-impl-report-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 : Graceful OSPF Restart Implementation Report Author(s) : A. Lindem Filename : draft-ietf-ospf-graceful-impl-report-01.txt Pages : 6 Date : 2004-1-29 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-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-graceful-impl-report-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-graceful-impl-report-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: <2004-1-30121139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-graceful-impl-report-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-graceful-impl-report-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30121139.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 31 06:56:04 2004 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 GAA18623 for ; Sat, 31 Jan 2004 06:56: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 <8.00CC652E@cherry.ease.lsoft.com>; Sat, 31 Jan 2004 6:56:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56734 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 31 Jan 2004 06:55:39 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 31 Jan 2004 06:55:39 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 31F016D1548 for ; Sat, 31 Jan 2004 03:55:39 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05243-08 for ; Sat, 31 Jan 2004 03:55:39 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.60]) by prattle.redback.com (Postfix) with SMTP id 694246D1544 for ; Sat, 31 Jan 2004 03:55:38 -0800 (PST) References: <001b01c3e698$9bf83ba0$f86445ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <05fa01c3e7f1$20df5e30$0302a8c0@aceeinspiron> Date: Sat, 31 Jan 2004 06:55:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-mirtorabi-ospfv3-af-alt-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This draft was presented at the last IETF and we discussed making it an OSPF WG document. Is there any further discussion. I'd propose that we make it a WG document. Thanks, Acee ----- Original Message ----- From: "Sina Mirtorabi" To: Sent: Thursday, January 29, 2004 1:49 PM Subject: I-D ACTION:draft-mirtorabi-ospfv3-af-alt-01.txt > Folks, > > A new version of address-family draft is available. The diffs are > > o Section 3, Instance ID range has been updated > > o Section 8, for IPv4 AF nexthop calculation, an IPv4 address will be > advertised in "link-local address filed" of Link-LSA. Previously this > address was advertised in prefix field with LA-bit set. > > o Section 9, adds the support of OSPFv3 over IPv4 > > o Section 10, VL support has been updated > > > Thanks > Sina > > -------------- > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Support of address families in OSPFv3 > Author(s) : S. Mirtorabi > Filename : draft-mirtorabi-ospfv3-af-alt-01.txt > Pages : 6 > Date : 2004-1-28 > > This document describes a mechanism for supporting multiple address > families in OSPFv3 using multiple instances. It maps an address family > (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 > packet header. This approach is fairly simple and minimizes extensions > to OSPFv3 for supporting multiple AF's. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af-alt-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-mirtorabi-ospfv3-af-alt-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-mirtorabi-ospfv3-af-alt-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. >