=A0=A0=A0 mter@ietf.org:=A0<= A href=3D"https://www1.ietf.org/mailman/listinfo/mter">https://www1.ietf.org/mailman/listinfo/mter

JP, = Jean-Louis and Raymond.

= --Apple-Mail-17-4186124-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 28 11:51:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgmEG-0002W5-QA for ospf-archive@megatron.ietf.org; Mon, 28 Nov 2005 11:51:48 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29903 for ; Mon, 28 Nov 2005 11:51:03 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.000039AE@wildebeest.ease.lsoft.com>; Mon, 28 Nov 2005 11:51:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 91975264 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 28 Nov 2005 11:51:14 -0500 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 28 Nov 2005 11:51:04 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA04949; Mon, 28 Nov 2005 08:51:02 -0800 (PST) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jASGp2C04375; Mon, 28 Nov 2005 10:51:02 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Nov 2005 08:50:55 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: evaluation plan for OSPF MANET Thread-Index: AcX0O+W53Sn4xrLaRNaJ3v20DZRNbw== X-OriginalArrivalTime: 28 Nov 2005 16:50:55.0408 (UTC) FILETIME=[E64E8300:01C5F43B] Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E6E1@XCH-NW-5V1.nw.nos.boeing.com> Date: Mon, 28 Nov 2005 08:50:55 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: evaluation plan for OSPF MANET Comments: To: ospf-manet@ietf.org, manet-dt@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Note: This message is intended to start new discussions. Replies **only** to ospf-manet@ietf.org. Now that we have established a list for this activity, I would like to suggest that the first order of business should be to agree upon a fair process whereby the OSPF WG is in a position to move forward on an OSPF MANET design by the March meeting. =20 A first step should be to agree upon what we are trying to decide. I believe that we are trying to decide upon whether the basis for efficient flooding and topology control for OSPF MANET should be a source-independent connected dominating set (specifically, Ogier's MDR proposal) or a source-dependent connected dominating set (specifically, Overlapping Relays with Smart Peering). =20 I also believe that, unless it is proven that the two current designs have significant performance differences in different operating environments, we are trying to downselect to one OSPF MANET design, not to define the operating regions most applicable to two separate designs. A second step should be to agree on evaluation criteria and scenarios, to address the comments at the WG meeting that the previously used scenarios were too narrow. This should be agreed upon within the next month or so, based on list discussion. The scenarios/criteria need to be feasible to achieve in the timeframe of this evaluation. A third step should be to allow time for the interested parties to study the proposed approaches in light of the above criteria. Simulation or implementation experiments can be used to support arguments, but are not required in any or all cases. I will take the action item to integrate the new Cisco code and post a new evaluation software release. A fourth step is to have any interested party submit a short position draft on the issue at hand. The position draft should be page limited (e.g., 10 pages) so that it is more accessible to a wider WG review, although it may reference additional supporting material. It would be recommended but not required that any simulation or implementation scripts used to justify the arguments be made available at this time as well (private simulation results should probably be treated with less confidence by the WG). Drafts should not be allowed later than the I-D cutoff date, and the publishing of such a draft should be required to make a formal presentation on this topic at the Dallas meeting.=20 The fifth step is to have discussion on the list between the I-D cutoff and the meeting, and presentations and discussions at the Dallas meeting. Comments? Tom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 28 15:24:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgpYT-0008Jy-5n for ospf-archive@megatron.ietf.org; Mon, 28 Nov 2005 15:24:53 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00496 for ; Mon, 28 Nov 2005 15:24:08 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.00003A07@wildebeest.ease.lsoft.com>; Mon, 28 Nov 2005 15:23:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 91994112 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 28 Nov 2005 15:23:12 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 28 Nov 2005 15:23:11 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2005 12:23:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,385,1125903600"; d="scan'208"; a="16107828:sNHT24067428" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jASKN9dr003205 for ; Mon, 28 Nov 2005 15:23:09 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 15:22:48 -0500 Received: from [10.82.216.212] ([10.82.216.212]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 15:22:48 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2005 20:22:48.0404 (UTC) FILETIME=[7FD7C140:01C5F459] Message-ID: <438B6717.7040700@cisco.com> Date: Mon, 28 Nov 2005 15:22:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: draft-ietf-ospf-ospfv3-traffic-06.txt Implementation Query To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit This version addresses comments during the previous WG last call. Due to the scope of the ASON requirements and their focus on OSPFv2, we have elected not to try and address ASON requirements in this draft. Please take a look at it. I know of at least one implementation - any others? Thanks, Acee Internet-Drafts@IETF.ORG wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : Traffic Engineering Extensions to OSPF version 3 > Author(s) : K. Ishiguro, et al. > Filename : draft-ietf-ospf-ospfv3-traffic-06.txt > Pages : 16 > Date : 2005-10-21 > >This document describes extensions to OSPFv3 to support intra-area > Traffic Engineering (TE). This document extends OSPFv2 TE to handle > IPv6 networks. A new TLV and several new sub-TLVs are defined to > support IPv6 networks. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-06.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ospf-ospfv3-traffic-06.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-06.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >------------------------------------------------------------------------- >CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY >------------------------------------------------------------------------- >In order to maintain computing infrastructure integrity, Cisco Systems >Enterprise Messaging Services and InfoSec teams have set a mail policy >disallowing executable attachments in email. > >This message contained an executable attachment type that is prohibited >by this policy. The attachment has been removed from this message and >copied to quarantine by our systems. It will be held in quarantine for >seven days in the event that the content needs to be retrieved. > >Please be aware many viruses attempt to look like legitimate email or >notifications from anti-virus systems. We will clearly mark a seperation >between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > >For further reference information about viruses and email antivirus >efforts within Cisco, please visit: > >http://wwwin.cisco.com/it/ems/services/antiviral > >If your concern isn't addressed by the information in this notification >or the above web page, you may open a support request: > >http://wwwin.cisco.com/support/ > >Select "Messaging", "Email-Related", "Mail Routing" > >Please include in the text of your case the following information: > >* Full headers of the message. Documentation on displaying the full >headers is available at this URL: > >http://wwwin.cisco.com/support/library/faqs/solution002471.html > >* This unique quarantine identifier: j9LJxp8u006230 > >If the matter is urgent, you may follow up by calling one of the below >referenced numbers. Please make every effort to provide the above >requested information via the support web tool prior to calling as it >will greatly aid the resolution of your issue. > >Americas: >1 408 526 8888 > >Asiapac >+61 2 8446 8888 > >EMEA >+31 20 485 4888 > >Japan >+81 3 5549 6888 > >US (Toll Free) >1| 800| 888| 8187| (ext.68888) > >Thank you for your cooperation, > >Enterprise Messaging Services >Cisco Systems, Inc > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 29 10:23:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh7KO-0004w8-PN for ospf-archive@megatron.ietf.org; Tue, 29 Nov 2005 10:23:34 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19533 for ; Tue, 29 Nov 2005 10:22:47 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00003B3F@wildebeest.ease.lsoft.com>; Tue, 29 Nov 2005 10:22:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92076006 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Nov 2005 10:23:00 -0500 Received: from 192.91.191.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 29 Nov 2005 10:22:59 -0500 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 15:22:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-traffic-06.txt Implementation Query Thread-Index: AcX0WY/eE3RVPTwoTS6XobntrtAToAAnrjmg X-OriginalArrivalTime: 29 Nov 2005 15:22:58.0649 (UTC) FILETIME=[C786BC90:01C5F4F8] Message-ID: <3162498CE3484844988B9D12C81A949F0991FB@enfimail1.datcon.co.uk> Date: Tue, 29 Nov 2005 15:22:58 -0000 Reply-To: Mailing List Sender: Mailing List From: Alan Davey Subject: Re: draft-ietf-ospf-ospfv3-traffic-06.txt Implementation Query To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Acee We have an implementation of this draft. Regards Alan ------------------------------------ Alan Davey Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: Alan.Davey@dataconnection.com Web: http://www.dataconnection.com =20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 > Behalf Of Acee Lindem > Sent: 28 November 2005 20:23 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: draft-ietf-ospf-ospfv3-traffic-06.txt Implementation Query >=20 > This version addresses comments during the previous WG last=20 > call. Due to the scope of the ASON requirements and their=20 > focus on OSPFv2, we have elected not to try and address ASON=20 > requirements in this draft. Please take a look at it. >=20 > I know of at least one implementation - any others? >=20 > Thanks, > Acee >=20 >=20 > Internet-Drafts@IETF.ORG wrote: >=20 > >A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > >This draft is a work item of the Open Shortest Path First=20 > IGP Working Group of the IETF. > > > > Title : Traffic Engineering Extensions to=20 > OSPF version 3 > > Author(s) : K. Ishiguro, et al. > > Filename : draft-ietf-ospf-ospfv3-traffic-06.txt > > Pages : 16 > > Date : 2005-10-21 > >=09 > >This document describes extensions to OSPFv3 to support intra-area > > Traffic Engineering (TE). This document extends OSPFv2=20 > TE to handle > > IPv6 networks. A new TLV and several new sub-TLVs are defined to > > support IPv6 networks. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-tr affic-06.t > >xt > > > >To remove yourself from the I-D Announcement list, send a message to=20 > >i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. > >You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > >to change your subscription settings. > > > > > >Internet-Drafts are also available by anonymous FTP. Login with the=20 > >username "anonymous" and a password of your e-mail address. After=20 > >logging in, type "cd internet-drafts" and then > > "get draft-ietf-ospf-ospfv3-traffic-06.txt". > > > >A list of Internet-Drafts directories can be found in=20 > >http://www.ietf.org/shadow.html or=20 > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-06.txt". > >=09 > >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=20 > 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. > > =09 > > =09 > >Below is the data which will enable a MIME compliant mail reader=20 > >implementation to automatically retrieve the ASCII version of the=20 > >Internet-Draft. > >------------------------------------------------------------- > ---------- > >-- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > >------------------------------------------------------------- > ---------- > >-- In order to maintain computing infrastructure integrity, Cisco=20 > >Systems Enterprise Messaging Services and InfoSec teams have=20 > set a mail=20 > >policy disallowing executable attachments in email. > > > >This message contained an executable attachment type that is=20 > prohibited=20 > >by this policy. The attachment has been removed from this=20 > message and=20 > >copied to quarantine by our systems. It will be held in=20 > quarantine for=20 > >seven days in the event that the content needs to be retrieved. > > > >Please be aware many viruses attempt to look like legitimate=20 > email or=20 > >notifications from anti-virus systems. We will clearly mark a=20 > >seperation between our notifications and the original email=20 > as follows: > > > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION=20 > TECHNOLOGY" > > > >For further reference information about viruses and email antivirus=20 > >efforts within Cisco, please visit: > > > >http://wwwin.cisco.com/it/ems/services/antiviral > > > >If your concern isn't addressed by the information in this=20 > notification=20 > >or the above web page, you may open a support request: > > > >http://wwwin.cisco.com/support/ > > > >Select "Messaging", "Email-Related", "Mail Routing" > > > >Please include in the text of your case the following information: > > > >* Full headers of the message. Documentation on displaying the full=20 > >headers is available at this URL: > > > >http://wwwin.cisco.com/support/library/faqs/solution002471.html > > > >* This unique quarantine identifier: j9LJxp8u006230 > > > >If the matter is urgent, you may follow up by calling one of=20 > the below=20 > >referenced numbers. Please make every effort to provide the above=20 > >requested information via the support web tool prior to=20 > calling as it=20 > >will greatly aid the resolution of your issue. > > > >Americas: > >1 408 526 8888 > > > >Asiapac > >+61 2 8446 8888 > > > >EMEA > >+31 20 485 4888 > > > >Japan > >+81 3 5549 6888 > > > >US (Toll Free) > >1| 800| 888| 8187| (ext.68888) > > > >Thank you for your cooperation, > > > >Enterprise Messaging Services > >Cisco Systems, Inc > > =20 > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 29 22:48:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhIx7-00069T-By for ospf-archive@megatron.ietf.org; Tue, 29 Nov 2005 22:48:17 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18782 for ; Tue, 29 Nov 2005 22:47:32 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.00003C5D@wildebeest.ease.lsoft.com>; Tue, 29 Nov 2005 22:47:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92133392 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Nov 2005 22:47:42 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 29 Nov 2005 22:37:37 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQR00JD7142GW@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Nov 2005 11:45:39 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQR00JN91422X@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Nov 2005 11:45:38 +0800 (CST) Received: from huaweizfbnwhb5 ([10.110.102.51]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IQR00LV81CPXR@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Nov 2005 11:50:49 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c5f55f$60e229e0$33666e0a@china.huawei.com> Date: Wed, 30 Nov 2005 11:37:24 +0800 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: About OSPF router advertisement capability To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3162498CE3484844988B9D12C81A949F0991FB@enfimail1.datcon.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-07.txt How are some implementations viewing this ? Any constructive comments ? Thanks, Abhay From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 30 08:15:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRoM-0002lW-7t for ospf-archive@megatron.ietf.org; Wed, 30 Nov 2005 08:15:50 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12976 for ; Wed, 30 Nov 2005 08:15:03 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00003CCB@wildebeest.ease.lsoft.com>; Wed, 30 Nov 2005 8:15:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92180737 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Nov 2005 08:15:19 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 30 Nov 2005 08:15:19 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Nov 2005 05:15:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,195,1131350400"; d="scan'208"; a="16225609:sNHT23345082" Received: from RussPC (rtp-vpn4-233.cisco.com [10.82.208.233]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAUDFElo010018; Wed, 30 Nov 2005 08:15:15 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Wed, 30 Nov 2005 08:15:15 -0500 X-PGP-Universal: processed; by RussPC on Wed, 30 Nov 2005 08:15:15 -0500 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E6E1@XCH-NW-5V1.nw.nos.boeing.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <438DA5DB.1090807@cisco.com> Date: Wed, 30 Nov 2005 08:15:07 -0500 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: [Ospf-manet] evaluation plan for OSPF MANET Comments: To: "Henderson, Thomas R" Comments: cc: ospf-manet@ietf.org, manet-dt@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E6E1@XCH-NW-5V1.nw.nos.boeing.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > A second step should be to agree on evaluation criteria and scenarios, > to address the comments at the WG meeting that the previously used > scenarios were too narrow. This should be agreed upon within the next > month or so, based on list discussion. The scenarios/criteria need to > be feasible to achieve in the timeframe of this evaluation. This presupposes emulations are "the" way to evaulate the proposals. In fact, I believe we need to do more traditional work here, such as examining pathological cases. For instance: o Is there a point in the mobility graph where the protocol mechanism simply won't converge when real rachability should be available in the network? o Is there a specific event that will cause a long outage in reachability when physical reachability still exists? o How much change to existing code do the proposed mechanisms cause? One of the reasons we're using OSPF here is to reuse as much of a known working protocol as possible in a different environment. If the proposed changes change entire sections of the OSPF code (1,000 lines sounds trivial, until you realize that most OSPF implementations are probably only 12,000 lines of code, and 1/12th doesn't sound so trivial any longer), then we don't want to mess with it--better to use a new protocol. o How extensible, into the future, are the proposed changes? Are they currently "at the end of the line," as optimal as they will ever get, or are there other areas of exploration to be done? If one mechanism has optimized all it can, and another shows similar improvements, but has many more possible optimizations, it's better to go with one that can be further optimized. These are the sorts of things we normally look at when examining a protocol change, rather than basing the change simply on simulation results. We all realize implementations have a huge impact on performance (you can implement SPF as n^2, or n(log n), for instance), and that you learn how to improve performance over time. Basing an initial modification based on simple performance in a simulator is the wrong way to work at the problem. Imagine the IETF choosing between IS-IS and OSPF based on simulation work (!). Simulations are interesting, but they don't indicate much of anything, until you get to simulating on real routers, and possibly even real radios (although I'm not so certain about that part, for various reasons). :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.3 (Build 2932) iQA/AwUBQ42l4xEdu7FIVPTkEQIviQCfUjtRIXA86u/zNk3PIymj4AWWEDoAnRv2 im5Q5RNTXluAj2My26N50mwV =0gOk -----END PGP SIGNATURE----- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 30 12:09:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVSC-0006zn-Kp for ospf-archive@megatron.ietf.org; Wed, 30 Nov 2005 12:09:12 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11612 for ; Wed, 30 Nov 2005 12:08:26 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00003D44@wildebeest.ease.lsoft.com>; Wed, 30 Nov 2005 12:08:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92205430 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Nov 2005 12:08:40 -0500 Received: from 207.69.195.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 30 Nov 2005 12:08:40 -0500 Received: from h-68-164-82-45.snvacaid.dynamic.covad.net ([68.164.82.45] helo=earthlink.net) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EhVRg-0004uN-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Nov 2005 12:08:40 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E6E1@XCH-NW-5V1.nw.nos.boeing.com> <438DA5DB.1090807@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <438D9BD9.B6A0E2D5@earthlink.net> Date: Wed, 30 Nov 2005 04:32:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: [Ospf-manet] evaluation plan for OSPF MANET To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Interesting, I was thinking on the same lines. But specific items also come to mind. * negotiated initialization params to ease adj formations. Ex: LDP peer negotiation. Wouldn't this allow a peer to move easier from area to area with diff adj params? * freq (in the case of mobility) drops of pkts where a session / connection oriented scheme may be warranted. Wouldn't we want to handoff to TCP these cases for rexmits??? * a very low overhead of periodic summation of parts of the LSDB so a pull method vs a push method of updates can be implimneted. Would this work better in the cases where a small number of peers are mobile? And scale using multicast where a larger nbr of peers are mobile? The trusted mobile peers make the requests and if trusted, use targeted hellos or .. AND responses are either uc or mc depending on the nbr of outstanding reqs. Ex: a mix of IS-IS and partial OSPF LSDB chksums.. * a spec'ed method to deter transit routing. * ??a spec'ed method to inform that a host is reaching a point between two handoff routers and if possible defer delivery of its pkts?? * a spec'ed method to state that a transition from a 2G to a 3G type connection (or vice versa) is occuring? * etc.. So, I am assuming that we are talking about a really diff type of envs versus current OSPF envs. Yes, I ask alot, but this is a new env and done right could superseed our current envs. Mitchell Erblich ---------------------- Russ White wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > A second step should be to agree on evaluation criteria and scenarios, > > to address the comments at the WG meeting that the previously used > > scenarios were too narrow. This should be agreed upon within the next > > month or so, based on list discussion. The scenarios/criteria need to > > be feasible to achieve in the timeframe of this evaluation. > > This presupposes emulations are "the" way to evaulate the proposals. In > fact, I believe we need to do more traditional work here, such as > examining pathological cases. For instance: > > o Is there a point in the mobility graph where the protocol mechanism > simply won't converge when real rachability should be available in the > network? > > o Is there a specific event that will cause a long outage in > reachability when physical reachability still exists? > > o How much change to existing code do the proposed mechanisms cause? One > of the reasons we're using OSPF here is to reuse as much of a known > working protocol as possible in a different environment. If the proposed > changes change entire sections of the OSPF code (1,000 lines sounds > trivial, until you realize that most OSPF implementations are probably > only 12,000 lines of code, and 1/12th doesn't sound so trivial any > longer), then we don't want to mess with it--better to use a new protocol. > > o How extensible, into the future, are the proposed changes? Are they > currently "at the end of the line," as optimal as they will ever get, or > are there other areas of exploration to be done? If one mechanism has > optimized all it can, and another shows similar improvements, but has > many more possible optimizations, it's better to go with one that can be > further optimized. > > These are the sorts of things we normally look at when examining a > protocol change, rather than basing the change simply on simulation > results. We all realize implementations have a huge impact on > performance (you can implement SPF as n^2, or n(log n), for instance), > and that you learn how to improve performance over time. Basing an > initial modification based on simple performance in a simulator is the > wrong way to work at the problem. Imagine the IETF choosing between > IS-IS and OSPF based on simulation work (!). > > Simulations are interesting, but they don't indicate much of anything, > until you get to simulating on real routers, and possibly even real > radios (although I'm not so certain about that part, for various reasons). > > :-) > > Russ > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.0.3 (Build 2932) > > iQA/AwUBQ42l4xEdu7FIVPTkEQIviQCfUjtRIXA86u/zNk3PIymj4AWWEDoAnRv2 > im5Q5RNTXluAj2My26N50mwV > =0gOk > -----END PGP SIGNATURE-----