From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 3 12:42:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12139 for ; Mon, 3 Nov 2003 12:42: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.00C33E1E@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 12:42:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59290265 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 12:42:48 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 12:42:48 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hA3Hgm9r077599 for ; Mon, 3 Nov 2003 09:42:48 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hA3HglK6077596 for ; Mon, 3 Nov 2003 09:42:48 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20031103094047.H77572@kummer.juniper.net> Date: Mon, 3 Nov 2003 09:42:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: TED To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list On Fri, 31 Oct 2003, sarah smith wrote: > I have two questions about the TED. Thanks to Acee and Kireeti for answering > me other questions! > > 1. Both TE LSA and network LSA are used in TE calculation. - how would we > use the network LSA for TE calculation? How is this stored in TED. Is it > only used for multi-access links ? How a network LSA is stored depends on your TED data structures, but typically, it will connect all nodes on a multi-access link -- and yes, it is only used for multi-access links. > 2. When we build TED, do we need to keep track of a link which is an ISIS or > OSPF or both? Completely up to you. Kireeti. ------- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 3 19:50:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06112 for ; Mon, 3 Nov 2003 19:50: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 <11.00C3478E@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 19:50:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59330489 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 19:50:43 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 19:50:43 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B15634ABED4 for ; Mon, 3 Nov 2003 16:50:42 -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 05906-07 for ; Mon, 3 Nov 2003 16:50:42 -0800 (PST) Received: from redback.com (unknown [155.53.6.27]) by prattle.redback.com (Postfix) with ESMTP id CA11E4ABED7 for ; Mon, 3 Nov 2003 16:50:41 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040108050407090908070600" Message-ID: <3FA6F7DD.6080001@redback.com> Date: Mon, 3 Nov 2003 19:50:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: 58th IETF OSPF WG Agenda To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------040108050407090908070600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've attached the agenda for the Minneapolis IETF. As you can see, we've got a full slate. Thanks, Acee --------------040108050407090908070600 Content-Type: text/plain; name="agenda-58.txt" Content-Disposition: inline; filename="agenda-58.txt" Content-Transfer-Encoding: 7bit Monday October 10 (15:30 - 17:30) ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins WG document status 10 Mins Chairs Graceful OSPF Restart Implementation Report 10 Mins Acee Lindem draft-ietf-ospf-graceful-impl-report-00.txt Support of address families in OSPFv3 10 Mins Rahul Aggarwal draft-mirtorabi-ospfv3-af-alt-00.txt Discussion 10 Mins Advertising a Router's Local Addresses in 10 Mins Rahul Aggrawal OSPF TE Extension draft-raggarwa-ospf-te-node-addr-00.txt OSPF Tunnel Adjacency 10 Mins Sina Mirtorabi draft-mirtorabi-ospf-tunnel-adjacency-00.txt Discussion 5 Mins OSPFv2 Traffic Engineering Extensions for 10 Mins Kiretti Kompella Multi-access Networks draft-kompella-ospf-multiaccess-te-00.txt Problem Statement for OSPF Extensions for 20 Mins Fred Baker Mobile Ad Hoc Routing draft-baker-manet-ospf-problem-statement-00 Discussion 20 Mins --------------040108050407090908070600-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 3 21:28:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09545 for ; Mon, 3 Nov 2003 21:28:54 -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.00C34B09@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 21:29:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59338113 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 21:29:01 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 21:29:01 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 48F6C78F488 for ; Mon, 3 Nov 2003 18:29:00 -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 06358-05 for ; Mon, 3 Nov 2003 18:29:00 -0800 (PST) Received: from redback.com (unknown [155.53.6.24]) by prattle.redback.com (Postfix) with ESMTP id 85EC078F496 for ; Mon, 3 Nov 2003 18:28:59 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020607090409090507050609" Message-ID: <3FA70EE8.8050001@redback.com> Date: Mon, 3 Nov 2003 21:28:56 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: 58th IETF OSPF WG Agenda Update To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------020607090409090507050609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've corrected the month and the amount of time requested for the MANET OSPF problem statement presentation and discussion. ) must admit that I'm relieved that we don't have every minute in the 2 hour slot allocated. Thanks, Acee --------------020607090409090507050609 Content-Type: text/plain; name="agenda-58.txt" Content-Disposition: inline; filename="agenda-58.txt" Content-Transfer-Encoding: 7bit Monday November 10 (15:30 - 17:30) ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins WG document status 10 Mins Chairs Graceful OSPF Restart Implementation Report 10 Mins Acee Lindem draft-ietf-ospf-graceful-impl-report-00.txt Support of address families in OSPFv3 10 Mins Rahul Aggarwal draft-mirtorabi-ospfv3-af-alt-00.txt Discussion 10 Mins Advertising a Router's Local Addresses in 10 Mins Rahul Aggrawal OSPF TE Extension draft-raggarwa-ospf-te-node-addr-00.txt OSPF Tunnel Adjacency 10 Mins Sina Mirtorabi draft-mirtorabi-ospf-tunnel-adjacency-00.txt Discussion 5 Mins OSPFv2 Traffic Engineering Extensions for 10 Mins Kiretti Kompella Multi-access Networks draft-kompella-ospf-multiaccess-te-00.txt Problem Statement for OSPF Extensions for 10 Mins Fred Baker Mobile Ad Hoc Routing draft-baker-manet-ospf-problem-statement-00 Discussion 10 Mins --------------020607090409090507050609-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 3 21:55:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10445 for ; Mon, 3 Nov 2003 21:55: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 <2.00C34A9D@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 21:55:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59339430 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 21:55:28 -0500 Received: from 207.159.120.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 21:55:28 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 21AA7B6C4; Mon, 3 Nov 2003 21:55:22 -0500 (EST) Received: from [64.47.48.10] by xprdmailfe18.nwk.excite.com via HTTP; Mon, 03 Nov 2003 21:55:22 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: <20031104025522.21AA7B6C4@xmxpita.excite.com> Date: Mon, 3 Nov 2003 21:55:22 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: 58th IETF OSPF WG Agenda Comments: To: acee@REDBACK.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Don't you mean November 10? Also, is there a new version of the draft-mirtorabi-ospf-tunnel-adjacency-xx.txt? Current version is 00 and I (and others) had made comments several months ago. -don =================================== I've attached the agenda for the Minneapolis IETF. As you can see, we've got a full slate. Thanks, Acee Monday October 10 (15:30 - 17:30) ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins WG document status 10 Mins Chairs Graceful OSPF Restart Implementation Report 10 Mins Acee Lindem draft-ietf-ospf-graceful-impl-report-00.txt Support of address families in OSPFv3 10 Mins Rahul Aggarwal draft-mirtorabi-ospfv3-af-alt-00.txt Discussion 10 Mins Advertising a Router's Local Addresses in 10 Mins Rahul Aggrawal OSPF TE Extension draft-raggarwa-ospf-te-node-addr-00.txt OSPF Tunnel Adjacency 10 Mins Sina Mirtorabi draft-mirtorabi-ospf-tunnel-adjacency-00.txt Discussion 5 Mins OSPFv2 Traffic Engineering Extensions for 10 Mins Kiretti Kompella Multi-access Networks draft-kompella-ospf-multiaccess-te-00.txt Problem Statement for OSPF Extensions for 20 Mins Fred Baker Mobile Ad Hoc Routing draft-baker-manet-ospf-problem-statement-00 Discussion 20 Mins _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 3 22:28:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11645 for ; Mon, 3 Nov 2003 22:28:46 -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.00C34AE3@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 22:28:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59340765 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 22:28:50 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 22:28:50 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A87D59F380C for ; Mon, 3 Nov 2003 19:28: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 13663-10 for ; Mon, 3 Nov 2003 19:28:49 -0800 (PST) Received: from redback.com (unknown [155.53.6.24]) by prattle.redback.com (Postfix) with ESMTP id 1171D9F380D for ; Mon, 3 Nov 2003 19:28:49 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20031104025522.21AA7B6C4@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FA71CEE.5050105@redback.com> Date: Mon, 3 Nov 2003 22:28:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: 58th IETF OSPF WG Agenda To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031104025522.21AA7B6C4@xmxpita.excite.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Don, Don Goodspeed wrote: >Acee, > >Don't you mean November 10? > :-) >Also, is there a new version >of the draft-mirtorabi-ospf-tunnel-adjacency-xx.txt? Current >version is 00 and I (and others) had made comments several >months ago. > I haven't seen any update but I believe the authors are presenting it as a candidate for acceptance by the WG. If this happens I'm sure they'll address all the comments received heretofore. Thanks, Acee > >-don > >=================================== >I've attached the agenda for the Minneapolis IETF. As you can see, we've >got a full >slate. > >Thanks, >Acee > >Monday October 10 (15:30 - 17:30) >================================= > >CHAIRS: Rohit Dube >Acee Lindem > >AGENDA: > >Agenda Bashing 5 Mins > >WG document status 10 Mins Chairs > >Graceful OSPF Restart Implementation Report 10 Mins Acee Lindem >draft-ietf-ospf-graceful-impl-report-00.txt > >Support of address families in OSPFv3 10 Mins Rahul Aggarwal >draft-mirtorabi-ospfv3-af-alt-00.txt >Discussion 10 Mins > >Advertising a Router's Local Addresses in 10 Mins Rahul Aggrawal >OSPF TE Extension >draft-raggarwa-ospf-te-node-addr-00.txt > >OSPF Tunnel Adjacency 10 Mins Sina Mirtorabi >draft-mirtorabi-ospf-tunnel-adjacency-00.txt >Discussion 5 Mins > >OSPFv2 Traffic Engineering Extensions for 10 Mins Kiretti Kompella >Multi-access Networks >draft-kompella-ospf-multiaccess-te-00.txt > >Problem Statement for OSPF Extensions for 20 Mins Fred Baker >Mobile Ad Hoc Routing >draft-baker-manet-ospf-problem-statement-00 >Discussion 20 Mins > > >_______________________________________________ >Join Excite! - http://www.excite.com >The most personalized portal on the Web! > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 4 17:51:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09509 for ; Tue, 4 Nov 2003 17:51:10 -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.00C36311@cherry.ease.lsoft.com>; Tue, 4 Nov 2003 17:51:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59469903 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 4 Nov 2003 17:51:17 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Nov 2003 17:51:17 -0400 Received: from smirtoraw2k03 (dhcp-171-69-100-236.cisco.com [171.69.100.236]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hA4MpFk25273 for ; Tue, 4 Nov 2003 14:51:15 -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: <00bc01c3a326$27a81f00$f2ce7243@amer.cisco.com> Date: Tue, 4 Nov 2003 14:51:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: 58th IETF OSPF WG Agenda To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031104025522.21AA7B6C4@xmxpita.excite.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Don, -> is there a new version ->of the draft-mirtorabi-ospf-tunnel-adjacency-xx.txt? The new version will be published after the ietf meeting ->Current version is 00 and I (and others) had made comments several months ago. All the comments will be included in the new version. Thanks Sina From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 4 18:17:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11266 for ; Tue, 4 Nov 2003 18:17: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 <10.00C36566@cherry.ease.lsoft.com>; Tue, 4 Nov 2003 18:17:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59472581 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 4 Nov 2003 18:17:33 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Nov 2003 18:17:29 -0400 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hA4NHQrX004891 for ; Tue, 4 Nov 2003 15:17:27 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (dhcp-10-86-162-228.cisco.com [10.86.162.228]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA10364; Tue, 4 Nov 2003 15:17:25 -0800 (PST) X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20031104180358.05f65cd0@wells.cisco.com> Date: Tue, 4 Nov 2003 18:17:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Jean Philippe Vasseur Subject: Re: 58th IETF OSPF WG Agenda To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FA6F7DD.6080001@redback.com> Precedence: list Hi Acee, You might remember an email that I sent out a few weeks ago regarding draft-vasseur-mpls-ospf-te-cap-00.txt. Actually I presented it at the last OSPF WG meeting in Vienna. Would you mind confirming that this draft goes to the OSPF WG ? Thanks. JP. At 07:50 PM 11/3/2003 -0500, Acee Lindem wrote: >I've attached the agenda for the Minneapolis IETF. As you can see, we've >got a full >slate. > >Thanks, >Acee > > >Monday October 10 (15:30 - 17:30) >================================= > >CHAIRS: Rohit Dube > Acee Lindem > >AGENDA: > >Agenda Bashing 5 Mins > >WG document status 10 Mins Chairs > >Graceful OSPF Restart Implementation Report 10 Mins Acee Lindem >draft-ietf-ospf-graceful-impl-report-00.txt > >Support of address families in OSPFv3 10 Mins Rahul Aggarwal >draft-mirtorabi-ospfv3-af-alt-00.txt > Discussion 10 Mins > >Advertising a Router's Local Addresses in 10 Mins Rahul Aggrawal >OSPF TE Extension >draft-raggarwa-ospf-te-node-addr-00.txt > >OSPF Tunnel Adjacency 10 Mins Sina Mirtorabi >draft-mirtorabi-ospf-tunnel-adjacency-00.txt > Discussion 5 Mins > >OSPFv2 Traffic Engineering Extensions for 10 Mins Kiretti Kompella >Multi-access Networks >draft-kompella-ospf-multiaccess-te-00.txt > >Problem Statement for OSPF Extensions for 20 Mins Fred Baker >Mobile Ad Hoc Routing >draft-baker-manet-ospf-problem-statement-00 > Discussion 20 Mins From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 5 12:23:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13637 for ; Wed, 5 Nov 2003 12:23: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 <23.00C379AB@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 12:23:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59472352 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 12:23:11 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 12:23:11 -0400 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 MAA04055 for ; Wed, 5 Nov 2003 12:23:09 -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 MAA22288 for ; Wed, 5 Nov 2003 12:23:10 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 12:23:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB70DC@vie-msgusr-01.dc.fore.com> Date: Wed, 5 Nov 2003 12:23:02 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: 58th IETF OSPF WG Agenda To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I might not attend Minneapolis IETF. Here are some concerns. -> >Advertising a Router's Local Addresses in 10 Mins -> Rahul Aggrawal -> >OSPF TE Extension -> >draft-raggarwa-ospf-te-node-addr-00.txt The above draft reads: OSPFv2 stub links in the router LSA [OSPFv2], provide stub reachability information to the router but are not sufficient to learn all the local addresses of a router. Aren't we duplicating the information in Router LSA and TE LSA ? We can use passive interface capability to flood this desired information using Router LSA. In other words, why is Router LSA stub info not *sufficient* to learn all local addresses (if we enable active/passive OSPF routing over all those interfaces) ? Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 6 05:21:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02879 for ; Thu, 6 Nov 2003 05:21: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 <9.00C38BEF@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 5:21:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59549053 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 05:21:24 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 05:21:24 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C38D39@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 5:21:24 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Message-ID: Date: Thu, 6 Nov 2003 05:21:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable All, Please consider the following topology: +---+ | +---+ |RUT|----|----|TR1| +---+ | +---+ Network 0 Part C: The RUT transitions to BDR 10. Unplug the RUT=92s interface on network 0. 11. Reset OSPF. 12. Plug the RUT=92s interface back in on network 0 (TR1 should still list RUT as BDR). 13. Observe the traffic transmitted on the network. Observable Results: In Part C, The RUT should wait for about 40 seconds before it begins to claim itself to be the BDR on network 0. I wonder whether the result expected by the test are correct, since the crucial part of it, the remark made within the parentheses in step 12, cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR respectively. When RUT is unplugged, reset (in OSPF context), and plugged again, it multicasts Hello listing no neighbors. TR1 notices loss of bi- directional communication with RUT and reelects itself as DR leaving the position of BDR vacant, while listing RUT as neighbor in the next outgoing Hello. RUT receives that Hello, establishes bi-directional communication with TR1 (as it sees itself in the list), and discerns that TR1 claims itself DR with no fellow BDR. Naturally, RUT reacts with the event BackupSeen, running DR/BDR election ending up in the position of BDR. The entire procedure lasts from 1 to 20 seconds, which is below RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary to the results expected by the test. Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 6 05:52:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03740 for ; Thu, 6 Nov 2003 05:52:37 -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.00C38C15@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 5:52:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59549589 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 05:52:46 -0500 Received: from 203.124.166.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 05:42:45 -0400 Received: from nevis_pune_xchg.pune.nevisnetworks.com (nevis_pune_xchg.pune.nevisnetworks.com [192.168.2.7]) by mail.pune.nevisnetworks.com (8.12.5/8.12.5) with ESMTP id hA6Ar4pX029458 for ; Thu, 6 Nov 2003 16:23:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: UNH, interoperability, test OSPF-1.5c Thread-Index: AcOkT9KNCHrNep+KQQ+NF8x58iQJ1gAARjNw Message-ID: <36993D449C7FA647BF43568E0793AB3E2396A7@nevis_pune_xchg.pune.nevisnetworks.com> Date: Thu, 6 Nov 2003 16:13:13 +0530 Reply-To: Mailing List Sender: Mailing List From: Vivek Gupta Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable As per RFC, When the Interface comes up Hello Timer is started.("Interface UP" event). =20 That implies the HELLO packet will be sent by RUT 10 seconds after the Interface came up.=20 Therefore, when RUT comes up it can receive HELLO packet from TR1 before it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till say that BDR is "RUT"( because the change hasn't been detected by TR1 till now). Now, at RUT no "Backupseen" event will be triggered and hence Wait timer need to expire and it will take 40 seconds for RUT to declare itself as BDR. Regards, Vivek -----Original Message----- From: Igor Miroshnik [mailto:IgorM@RADLAN.COM]=20 Sent: Thursday, November 06, 2003 3:51 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: UNH, interoperability, test OSPF-1.5c All, Please consider the following topology: +---+ | +---+ |RUT|----|----|TR1| +---+ | +---+ Network 0 Part C: The RUT transitions to BDR 10. Unplug the RUT's interface on network 0. 11. Reset OSPF. 12. Plug the RUT's interface back in on network 0 (TR1 should still list RUT as BDR). 13. Observe the traffic transmitted on the network. Observable Results: In Part C, The RUT should wait for about 40 seconds before it begins to claim itself to be the BDR on network 0. I wonder whether the result expected by the test are correct, since the crucial part of it, the remark made within the parentheses in step 12, cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR respectively. When RUT is unplugged, reset (in OSPF context), and plugged again, it multicasts Hello listing no neighbors. TR1 notices loss of bi- directional communication with RUT and reelects itself as DR leaving the position of BDR vacant, while listing RUT as neighbor in the next outgoing Hello. RUT receives that Hello, establishes bi-directional communication with TR1 (as it sees itself in the list), and discerns that TR1 claims itself DR with no fellow BDR. Naturally, RUT reacts with the event BackupSeen, running DR/BDR election ending up in the position of BDR. The entire procedure lasts from 1 to 20 seconds, which is below RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary to the results expected by the test. Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 6 06:25:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04580 for ; Thu, 6 Nov 2003 06:25:49 -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.00C38E27@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 6:26:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59576452 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 06:25:59 -0500 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 06:25:59 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <15.0039B295@grape.ease.lsoft.com>; Thu, 6 Nov 2003 6:25:58 -0500 Message-ID: Date: Thu, 6 Nov 2003 06:25:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Vivek, Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still notices that RUT is no longer declaring itself as BDR, thus raising NeighborChange event. The latter results in DR/BDR reelection and the next TR1's Hello (another HelloInterval-delay, at most) will indicate lack of BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again, 20 seconds from RUT's comeback elapse, at most. Thanks you, Igor On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta wrote: >As per RFC, When the Interface comes up Hello Timer is >started.("Interface UP" event). > >That implies the HELLO packet will be sent by RUT 10 seconds after the >Interface came up. > >Therefore, when RUT comes up it can receive HELLO packet from TR1 before >it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till >say that BDR is "RUT"( because the change hasn't been detected by TR1 >till now). > >Now, at RUT no "Backupseen" event will be triggered and hence Wait timer >need to expire and it will take 40 seconds for RUT to declare itself as >BDR. > >Regards, >Vivek > >-----Original Message----- >From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >Sent: Thursday, November 06, 2003 3:51 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: UNH, interoperability, test OSPF-1.5c > >All, > > Please consider the following topology: > > +---+ | +---+ > |RUT|----|----|TR1| > +---+ | +---+ > Network 0 > >Part C: The RUT transitions to BDR > > 10. Unplug the RUT's interface on network 0. > 11. Reset OSPF. > 12. Plug the RUT's interface back in on network 0 (TR1 should still > list RUT as BDR). > 13. Observe the traffic transmitted on the network. > >Observable Results: > > In Part C, The RUT should wait for about 40 seconds before it > begins to claim itself to be the BDR on network 0. > > > > I wonder whether the result expected by the test are correct, since >the crucial part of it, the remark made within the parentheses in step >12, >cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR >respectively. When RUT is unplugged, reset (in OSPF context), and >plugged >again, it multicasts Hello listing no neighbors. TR1 notices loss of bi- >directional communication with RUT and reelects itself as DR leaving the >position of BDR vacant, while listing RUT as neighbor in the next >outgoing >Hello. RUT receives that Hello, establishes bi-directional communication >with TR1 (as it sees itself in the list), and discerns that TR1 claims >itself DR with no fellow BDR. Naturally, RUT reacts with the event >BackupSeen, running DR/BDR election ending up in the position of BDR. >The >entire procedure lasts from 1 to 20 seconds, which is below >RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary to >the results expected by the test. > >Thanks, >Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 6 06:38:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04894 for ; Thu, 6 Nov 2003 06:38: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 <21.00C38FBE@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 6:38:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59579237 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 06:38:16 -0500 Received: from 203.124.166.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 06:38:15 -0400 Received: from nevis_pune_xchg.pune.nevisnetworks.com (nevis_pune_xchg.pune.nevisnetworks.com [192.168.2.7]) by mail.pune.nevisnetworks.com (8.12.5/8.12.5) with ESMTP id hA6BmapX029549 for ; Thu, 6 Nov 2003 17:18:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: UNH, interoperability, test OSPF-1.5c Thread-Index: AcOkWNdeJyvoH36uTlGHcJDhq5J06wAAMkCg Message-ID: <36993D449C7FA647BF43568E0793AB3E2396A9@nevis_pune_xchg.pune.nevisnetworks.com> Date: Thu, 6 Nov 2003 17:08:45 +0530 Reply-To: Mailing List Sender: Mailing List From: Vivek Gupta Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable BackupSeen event will still not be raised, because on TR1 when Neighbor Change event occurs, DR election will still lead to election of RUT as BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain any change and hence no BACKUP SEEN event on RUT. Regards, Vivek -----Original Message----- From: Igor Miroshnik [mailto:IgorM@RADLAN.COM]=20 Sent: Thursday, November 06, 2003 4:56 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: UNH, interoperability, test OSPF-1.5c Vivek, Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still notices that RUT is no longer declaring itself as BDR, thus raising NeighborChange event. The latter results in DR/BDR reelection and the next TR1's Hello (another HelloInterval-delay, at most) will indicate lack of BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again, 20 seconds from RUT's comeback elapse, at most. Thanks you, Igor On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta wrote: >As per RFC, When the Interface comes up Hello Timer is >started.("Interface UP" event). > >That implies the HELLO packet will be sent by RUT 10 seconds after the >Interface came up. > >Therefore, when RUT comes up it can receive HELLO packet from TR1 before >it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till >say that BDR is "RUT"( because the change hasn't been detected by TR1 >till now). > >Now, at RUT no "Backupseen" event will be triggered and hence Wait timer >need to expire and it will take 40 seconds for RUT to declare itself as >BDR. > >Regards, >Vivek > >-----Original Message----- >From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >Sent: Thursday, November 06, 2003 3:51 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: UNH, interoperability, test OSPF-1.5c > >All, > > Please consider the following topology: > > +---+ | +---+ > |RUT|----|----|TR1| > +---+ | +---+ > Network 0 > >Part C: The RUT transitions to BDR > > 10. Unplug the RUT's interface on network 0. > 11. Reset OSPF. > 12. Plug the RUT's interface back in on network 0 (TR1 should still > list RUT as BDR). > 13. Observe the traffic transmitted on the network. > >Observable Results: > > In Part C, The RUT should wait for about 40 seconds before it > begins to claim itself to be the BDR on network 0. > > > > I wonder whether the result expected by the test are correct, since >the crucial part of it, the remark made within the parentheses in step >12, >cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR >respectively. When RUT is unplugged, reset (in OSPF context), and >plugged >again, it multicasts Hello listing no neighbors. TR1 notices loss of bi- >directional communication with RUT and reelects itself as DR leaving the >position of BDR vacant, while listing RUT as neighbor in the next >outgoing >Hello. RUT receives that Hello, establishes bi-directional communication >with TR1 (as it sees itself in the list), and discerns that TR1 claims >itself DR with no fellow BDR. Naturally, RUT reacts with the event >BackupSeen, running DR/BDR election ending up in the position of BDR. >The >entire procedure lasts from 1 to 20 seconds, which is below >RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary to >the results expected by the test. > >Thanks, >Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 6 09:20:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09716 for ; Thu, 6 Nov 2003 09:20:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C39175@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 9:20:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59586055 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 09:20:46 -0500 Received: from 209.119.1.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 09:20:46 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.FE6CBB94@wnt.dc.lsoft.com>; Thu, 6 Nov 2003 9:20:46 -0500 Message-ID: Date: Thu, 6 Nov 2003 09:20:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Group, I am confused: On one hand Vivek insists the first Hello should not be issued before HelloInterval elapses, on the other hand John http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0005&L=ospf&P=R432&I=-3 and Alex http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0006&L=ospf&D=0&I=-3&P=3123 mention immediate launch of Hello with InterfaceUp. Please help to make up my mind. Thanks, Igor On Thu, 6 Nov 2003 17:08:45 +0530, Vivek Gupta wrote: >BackupSeen event will still not be raised, because on TR1 when Neighbor >Change event occurs, DR election will still lead to election of RUT as >BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain any >change and hence no BACKUP SEEN event on RUT. > >Regards, >Vivek > >-----Original Message----- >From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >Sent: Thursday, November 06, 2003 4:56 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: UNH, interoperability, test OSPF-1.5c > >Vivek, > >Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still >notices that RUT is no longer declaring itself as BDR, thus raising >NeighborChange event. The latter results in DR/BDR reelection and the >next >TR1's Hello (another HelloInterval-delay, at most) will indicate lack of >BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again, >20 >seconds from RUT's comeback elapse, at most. > >Thanks you, >Igor > >On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta > wrote: > >>As per RFC, When the Interface comes up Hello Timer is >>started.("Interface UP" event). >> >>That implies the HELLO packet will be sent by RUT 10 seconds after the >>Interface came up. >> >>Therefore, when RUT comes up it can receive HELLO packet from TR1 >before >>it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till >>say that BDR is "RUT"( because the change hasn't been detected by TR1 >>till now). >> >>Now, at RUT no "Backupseen" event will be triggered and hence Wait >timer >>need to expire and it will take 40 seconds for RUT to declare itself as >>BDR. >> >>Regards, >>Vivek >> >>-----Original Message----- >>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>Sent: Thursday, November 06, 2003 3:51 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: UNH, interoperability, test OSPF-1.5c >> >>All, >> >> Please consider the following topology: >> >> +---+ | +---+ >> |RUT|----|----|TR1| >> +---+ | +---+ >> Network 0 >> >>Part C: The RUT transitions to BDR >> >> 10. Unplug the RUT's interface on network 0. >> 11. Reset OSPF. >> 12. Plug the RUT's interface back in on network 0 (TR1 should still >> list RUT as BDR). >> 13. Observe the traffic transmitted on the network. >> >>Observable Results: >> >> In Part C, The RUT should wait for about 40 seconds before it >> begins to claim itself to be the BDR on network 0. >> >> >> >> I wonder whether the result expected by the test are correct, since >>the crucial part of it, the remark made within the parentheses in step >>12, >>cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR >>respectively. When RUT is unplugged, reset (in OSPF context), and >>plugged >>again, it multicasts Hello listing no neighbors. TR1 notices loss of >bi- >>directional communication with RUT and reelects itself as DR leaving >the >>position of BDR vacant, while listing RUT as neighbor in the next >>outgoing >>Hello. RUT receives that Hello, establishes bi-directional >communication >>with TR1 (as it sees itself in the list), and discerns that TR1 claims >>itself DR with no fellow BDR. Naturally, RUT reacts with the event >>BackupSeen, running DR/BDR election ending up in the position of BDR. >>The >>entire procedure lasts from 1 to 20 seconds, which is below >>RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary >to >>the results expected by the test. >> >>Thanks, >>Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 6 09:32:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10501 for ; Thu, 6 Nov 2003 09:32:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C390E7@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 9:32:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59586150 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 09:32:47 -0500 Received: from 61.95.163.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 09:22:46 -0400 Received: from vishwas ([192.168.10.115]) by localhost.localdomain (8.12.5/8.12.5) with SMTP id hA6EJjTo005098 for ; Thu, 6 Nov 2003 19:49:46 +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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <00c601c3a48f$4561c5e0$730aa8c0@vishwas> Date: Thu, 6 Nov 2003 19:56:13 +0200 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi, Though I am have not really followed the thread. For the question you raise either ways is ok. Though sending it immediately helps in faster convergence. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor Miroshnik Sent: Thursday, November 06, 2003 4:21 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: UNH, interoperability, test OSPF-1.5c Group, I am confused: On one hand Vivek insists the first Hello should not be issued before HelloInterval elapses, on the other hand John http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0005&L=ospf&P=R432&I=-3 and Alex http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0006&L=ospf&D=0&I=-3&P=3123 mention immediate launch of Hello with InterfaceUp. Please help to make up my mind. Thanks, Igor On Thu, 6 Nov 2003 17:08:45 +0530, Vivek Gupta wrote: >BackupSeen event will still not be raised, because on TR1 when Neighbor >Change event occurs, DR election will still lead to election of RUT as >BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain any >change and hence no BACKUP SEEN event on RUT. > >Regards, >Vivek > >-----Original Message----- >From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >Sent: Thursday, November 06, 2003 4:56 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: UNH, interoperability, test OSPF-1.5c > >Vivek, > >Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still >notices that RUT is no longer declaring itself as BDR, thus raising >NeighborChange event. The latter results in DR/BDR reelection and the >next >TR1's Hello (another HelloInterval-delay, at most) will indicate lack of >BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again, >20 >seconds from RUT's comeback elapse, at most. > >Thanks you, >Igor > >On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta > wrote: > >>As per RFC, When the Interface comes up Hello Timer is >>started.("Interface UP" event). >> >>That implies the HELLO packet will be sent by RUT 10 seconds after the >>Interface came up. >> >>Therefore, when RUT comes up it can receive HELLO packet from TR1 >before >>it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till >>say that BDR is "RUT"( because the change hasn't been detected by TR1 >>till now). >> >>Now, at RUT no "Backupseen" event will be triggered and hence Wait >timer >>need to expire and it will take 40 seconds for RUT to declare itself as >>BDR. >> >>Regards, >>Vivek >> >>-----Original Message----- >>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>Sent: Thursday, November 06, 2003 3:51 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: UNH, interoperability, test OSPF-1.5c >> >>All, >> >> Please consider the following topology: >> >> +---+ | +---+ >> |RUT|----|----|TR1| >> +---+ | +---+ >> Network 0 >> >>Part C: The RUT transitions to BDR >> >> 10. Unplug the RUT's interface on network 0. >> 11. Reset OSPF. >> 12. Plug the RUT's interface back in on network 0 (TR1 should still >> list RUT as BDR). >> 13. Observe the traffic transmitted on the network. >> >>Observable Results: >> >> In Part C, The RUT should wait for about 40 seconds before it >> begins to claim itself to be the BDR on network 0. >> >> >> >> I wonder whether the result expected by the test are correct, since >>the crucial part of it, the remark made within the parentheses in step >>12, >>cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR >>respectively. When RUT is unplugged, reset (in OSPF context), and >>plugged >>again, it multicasts Hello listing no neighbors. TR1 notices loss of >bi- >>directional communication with RUT and reelects itself as DR leaving >the >>position of BDR vacant, while listing RUT as neighbor in the next >>outgoing >>Hello. RUT receives that Hello, establishes bi-directional >communication >>with TR1 (as it sees itself in the list), and discerns that TR1 claims >>itself DR with no fellow BDR. Naturally, RUT reacts with the event >>BackupSeen, running DR/BDR election ending up in the position of BDR. >>The >>entire procedure lasts from 1 to 20 seconds, which is below >>RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary >to >>the results expected by the test. >> >>Thanks, >>Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 6 09:35:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10611 for ; Thu, 6 Nov 2003 09:35: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 <22.00C391D8@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 9:35:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59586729 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 09:35:53 -0500 Received: from 203.124.166.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 09:35:53 -0400 Received: from nevis_pune_xchg.pune.nevisnetworks.com (nevis_pune_xchg.pune.nevisnetworks.com [192.168.2.7]) by mail.pune.nevisnetworks.com (8.12.5/8.12.5) with ESMTP id hA6EkBpX029747 for ; Thu, 6 Nov 2003 20:16:14 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: UNH, interoperability, test OSPF-1.5c Thread-Index: AcOkcUOLRhqAmr3XQ32iSDfwuiDSdwAAcHeA Message-ID: <36993D449C7FA647BF43568E0793AB3E23997B@nevis_pune_xchg.pune.nevisnetworks.com> Date: Thu, 6 Nov 2003 20:06:14 +0530 Reply-To: Mailing List Sender: Mailing List From: Vivek Gupta Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I was referring with regards to conformance. However, otherwise sending the HELLO packet at the InterfaceUp event leads to faster convergence. It is a kind of optimization. Regards, Vivek -----Original Message----- From: Igor Miroshnik [mailto:IgorM@RADLAN.COM]=20 Sent: Thursday, November 06, 2003 7:51 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: UNH, interoperability, test OSPF-1.5c Group, I am confused: On one hand Vivek insists the first Hello should not be issued before HelloInterval elapses, on the other hand John http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0005&L=3Dospf&P=3DR432= &I=3D-3 and Alex http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0006&L=3Dospf&D=3D0&I=3D= -3&P=3D 3123 mention immediate launch of Hello with InterfaceUp. Please help to make up my mind. Thanks, Igor On Thu, 6 Nov 2003 17:08:45 +0530, Vivek Gupta wrote: >BackupSeen event will still not be raised, because on TR1 when Neighbor >Change event occurs, DR election will still lead to election of RUT as >BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain any >change and hence no BACKUP SEEN event on RUT. > >Regards, >Vivek > >-----Original Message----- >From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >Sent: Thursday, November 06, 2003 4:56 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: UNH, interoperability, test OSPF-1.5c > >Vivek, > >Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still >notices that RUT is no longer declaring itself as BDR, thus raising >NeighborChange event. The latter results in DR/BDR reelection and the >next >TR1's Hello (another HelloInterval-delay, at most) will indicate lack of >BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again, >20 >seconds from RUT's comeback elapse, at most. > >Thanks you, >Igor > >On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta > wrote: > >>As per RFC, When the Interface comes up Hello Timer is >>started.("Interface UP" event). >> >>That implies the HELLO packet will be sent by RUT 10 seconds after the >>Interface came up. >> >>Therefore, when RUT comes up it can receive HELLO packet from TR1 >before >>it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till >>say that BDR is "RUT"( because the change hasn't been detected by TR1 >>till now). >> >>Now, at RUT no "Backupseen" event will be triggered and hence Wait >timer >>need to expire and it will take 40 seconds for RUT to declare itself as >>BDR. >> >>Regards, >>Vivek >> >>-----Original Message----- >>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>Sent: Thursday, November 06, 2003 3:51 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: UNH, interoperability, test OSPF-1.5c >> >>All, >> >> Please consider the following topology: >> >> +---+ | +---+ >> |RUT|----|----|TR1| >> +---+ | +---+ >> Network 0 >> >>Part C: The RUT transitions to BDR >> >> 10. Unplug the RUT's interface on network 0. >> 11. Reset OSPF. >> 12. Plug the RUT's interface back in on network 0 (TR1 should still >> list RUT as BDR). >> 13. Observe the traffic transmitted on the network. >> >>Observable Results: >> >> In Part C, The RUT should wait for about 40 seconds before it >> begins to claim itself to be the BDR on network 0. >> >> >> >> I wonder whether the result expected by the test are correct, since >>the crucial part of it, the remark made within the parentheses in step >>12, >>cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR >>respectively. When RUT is unplugged, reset (in OSPF context), and >>plugged >>again, it multicasts Hello listing no neighbors. TR1 notices loss of >bi- >>directional communication with RUT and reelects itself as DR leaving >the >>position of BDR vacant, while listing RUT as neighbor in the next >>outgoing >>Hello. RUT receives that Hello, establishes bi-directional >communication >>with TR1 (as it sees itself in the list), and discerns that TR1 claims >>itself DR with no fellow BDR. Naturally, RUT reacts with the event >>BackupSeen, running DR/BDR election ending up in the position of BDR. >>The >>entire procedure lasts from 1 to 20 seconds, which is below >>RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary >to >>the results expected by the test. >> >>Thanks, >>Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 6 21:27:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13175 for ; Thu, 6 Nov 2003 21:27:46 -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.00C3A0AA@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 21:27:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59652938 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 21:27:54 -0500 Received: from 61.140.60.52 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 21:27:53 -0400 Received: from wild([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm223fab2a85; Fri, 07 Nov 2003 10:41:26 +0800 Received: from wild([211.80.36.168]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Fri, 07 Nov 2003 10:41:26 +0800 X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-AIMC-AUTH: xiaoguiwxd X-AIMC-MAILFROM: xiaoguiwxd@21cn.com Message-ID: <5n968892895873.09263@send5.inner-21cn.com> Date: Fri, 7 Nov 2003 10:27:47 +0800 Reply-To: Mailing List Sender: Mailing List From: Jason Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 T1NQRqOsxPq6w6OhDQoNCgkNCg0KoaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQogCQkJCQ0KDQqh oaGhoaGhoaGhoaGhoaGhSmFzb24NCqGhoaGhoaGhoaGhoaGhoaF4aWFvZ3Vpd3hkQDIxY24uY29t DQqhoaGhoaGhoaGhoaGhoaGhMjAwMy0xMS0wNw0K From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 7 11:00:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20014 for ; Fri, 7 Nov 2003 11:00:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C3B101@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 11:00:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59729150 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 11:00:45 -0500 Received: from 208.236.67.14 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 11:00:45 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hA7G0UmR009307 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 7 Nov 2003 11:00:38 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id hA7G0O62024942 for ; Fri, 7 Nov 2003 11:00:25 -0500 (EST) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 11/07/2003 10:58:26 AM, Serialize complete at 11/07/2003 10:58:26 AM Content-Type: multipart/alternative; boundary="=_alternative 0057EFF785256DD7_=" Message-ID: Date: Fri, 7 Nov 2003 11:00:30 -0500 Reply-To: Mailing List Sender: Mailing List From: ashgoel@HSS.HNS.COM Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart message in MIME format. --=_alternative 0057EFF785256DD7_= Content-Type: text/plain; charset="us-ascii" --=_alternative 0057EFF785256DD7_= Content-Type: text/html; charset="us-ascii" --=_alternative 0057EFF785256DD7_=-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 7 11:18:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20622 for ; Fri, 7 Nov 2003 11:17:59 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C3B155@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 11:18:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59729963 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 11:18:08 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 11:18:07 -0400 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 ; Fri, 7 Nov 2003 21:46:53 +0530 Received: from rameshrr (rameshrr.future.futsoft.com [10.8.7.24]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id hA7G7j301637 for ; Fri, 7 Nov 2003 21:37:45 +0530 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Message-ID: <000f01c3a549$4fa7d2a0$1807080a@future.futsoft.com> Date: Fri, 7 Nov 2003 21:37:56 +0530 Reply-To: Mailing List Sender: Mailing List From: Rayapureddi Ramesh Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable
 


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

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************=
From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 7 16:45:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09330 for ; Fri, 7 Nov 2003 16:45:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C3B727@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 16:45:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59756567 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 16:45:49 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 16:45:49 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3C48E825327 for ; Fri, 7 Nov 2003 13:45:48 -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 09085-09 for ; Fri, 7 Nov 2003 13:45:46 -0800 (PST) Received: from redback.com (unknown [155.53.6.3]) by prattle.redback.com (Postfix) with ESMTP id 15D95825325 for ; Fri, 7 Nov 2003 13:44:56 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <00c601c3a48f$4561c5e0$730aa8c0@vishwas> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FAC1249.9080505@redback.com> Date: Fri, 7 Nov 2003 16:44:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <00c601c3a48f$4561c5e0$730aa8c0@vishwas> Precedence: list Content-Transfer-Encoding: 7bit In any case, I don't think the RUT should take RouterDeadInterval seconds to get the BackupSeen event and leave Wait state. I would think that once TR1 receives a hello from RUT, it will generate a NeigbborChange event and RUT will no longer be listed as BDR in TR1's helllos. This, in turn, will result in a BackupSeen event (since the TR1's BDR hello field is 0.0.0.0) on RUT and will cancel the WAIT timer. Regarding test suites, you should always take the specification as the final word. At one point, I informed a very reputable test vendor (which will remain unnamed) that their OSPF database exchange test script was incorrect. Their response was that I didn't have a valid service contract - of course I wasn't WG co-chair at that time :^). Vishwas Manral wrote: >Hi, > >Though I am have not really followed the thread. > >For the question you raise either ways is ok. Though sending it immediately >helps in faster convergence. > >Thanks, >Vishwas > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor >Miroshnik >Sent: Thursday, November 06, 2003 4:21 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: UNH, interoperability, test OSPF-1.5c > > >Group, > >I am confused: > >On one hand Vivek insists the first Hello should not be issued before >HelloInterval elapses, on the other hand >John >http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0005&L=ospf&P=R432&I=-3 >and Alex >http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0006&L=ospf&D=0&I=-3&P=3123 >mention immediate launch of Hello with InterfaceUp. >Please help to make up my mind. > >Thanks, >Igor > >On Thu, 6 Nov 2003 17:08:45 +0530, Vivek Gupta > wrote: > > > >>BackupSeen event will still not be raised, because on TR1 when Neighbor >>Change event occurs, DR election will still lead to election of RUT as >>BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain any >>change and hence no BACKUP SEEN event on RUT. >> >>Regards, >>Vivek >> >>-----Original Message----- >>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>Sent: Thursday, November 06, 2003 4:56 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: UNH, interoperability, test OSPF-1.5c >> >>Vivek, >> >>Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still >>notices that RUT is no longer declaring itself as BDR, thus raising >>NeighborChange event. The latter results in DR/BDR reelection and the >>next >>TR1's Hello (another HelloInterval-delay, at most) will indicate lack of >>BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again, >>20 >>seconds from RUT's comeback elapse, at most. >> >>Thanks you, >>Igor >> >>On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta >> wrote: >> >> >> >>>As per RFC, When the Interface comes up Hello Timer is >>>started.("Interface UP" event). >>> >>>That implies the HELLO packet will be sent by RUT 10 seconds after the >>>Interface came up. >>> >>>Therefore, when RUT comes up it can receive HELLO packet from TR1 >>> >>> >>before >> >> >>>it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till >>>say that BDR is "RUT"( because the change hasn't been detected by TR1 >>>till now). >>> >>>Now, at RUT no "Backupseen" event will be triggered and hence Wait >>> >>> >>timer >> >> >>>need to expire and it will take 40 seconds for RUT to declare itself as >>>BDR. >>> >>>Regards, >>>Vivek >>> >>>-----Original Message----- >>>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>>Sent: Thursday, November 06, 2003 3:51 PM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: UNH, interoperability, test OSPF-1.5c >>> >>>All, >>> >>>Please consider the following topology: >>> >>> +---+ | +---+ >>> |RUT|----|----|TR1| >>> +---+ | +---+ >>> Network 0 >>> >>>Part C: The RUT transitions to BDR >>> >>>10. Unplug the RUT's interface on network 0. >>>11. Reset OSPF. >>>12. Plug the RUT's interface back in on network 0 (TR1 should still >>> list RUT as BDR). >>>13. Observe the traffic transmitted on the network. >>> >>>Observable Results: >>> >>>In Part C, The RUT should wait for about 40 seconds before it >>>begins to claim itself to be the BDR on network 0. >>> >>> >>> >>>I wonder whether the result expected by the test are correct, since >>>the crucial part of it, the remark made within the parentheses in step >>>12, >>>cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR >>>respectively. When RUT is unplugged, reset (in OSPF context), and >>>plugged >>>again, it multicasts Hello listing no neighbors. TR1 notices loss of >>> >>> >>bi- >> >> >>>directional communication with RUT and reelects itself as DR leaving >>> >>> >>the >> >> >>>position of BDR vacant, while listing RUT as neighbor in the next >>>outgoing >>>Hello. RUT receives that Hello, establishes bi-directional >>> >>> >>communication >> >> >>>with TR1 (as it sees itself in the list), and discerns that TR1 claims >>>itself DR with no fellow BDR. Naturally, RUT reacts with the event >>>BackupSeen, running DR/BDR election ending up in the position of BDR. >>>The >>>entire procedure lasts from 1 to 20 seconds, which is below >>>RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary >>> >>> >>to >> >> >>>the results expected by the test. >>> >>>Thanks, >>>Igor >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Nov 8 03:25:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10346 for ; Sat, 8 Nov 2003 03:25:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C3C2C7@cherry.ease.lsoft.com>; Sat, 8 Nov 2003 3:25:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59798489 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 8 Nov 2003 03:25:45 -0500 Received: from 203.124.166.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 8 Nov 2003 03:25:44 -0400 Received: from nevis_pune_xchg.pune.nevisnetworks.com (nevis_pune_xchg.pune.nevisnetworks.com [192.168.2.7]) by mail.pune.nevisnetworks.com (8.12.5/8.12.5) with ESMTP id hA88aFpX031968 for ; Sat, 8 Nov 2003 14:06:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: UNH, interoperability, test OSPF-1.5c Thread-Index: AcOleJ7LJg18xmswQ82xXZF/IU7cPwAWSw1g Message-ID: <36993D449C7FA647BF43568E0793AB3E239981@nevis_pune_xchg.pune.nevisnetworks.com> Date: Sat, 8 Nov 2003 13:56:23 +0530 Reply-To: Mailing List Sender: Mailing List From: Vivek Gupta Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable BackupSeen event will not be raised, because on TR1 when Neighbor Change event occurs, DR election will lead to election of "RUT" as BDR and "TR1" as DR. So, the Hello packet sent by TR1 will still contain "RUT" as TR1 and hence no BACKUP SEEN event on RUT will be triggered. Regards, Vivek -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM]=20 Sent: Saturday, November 08, 2003 3:15 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: UNH, interoperability, test OSPF-1.5c In any case, I don't think the RUT should take RouterDeadInterval seconds to get the BackupSeen event and leave Wait state. I would think that once TR1 receives a hello from RUT, it will generate a NeigbborChange event and RUT will no longer be listed as BDR in TR1's helllos. This, in turn, will result in a BackupSeen event (since the TR1's BDR hello field is 0.0.0.0) on RUT and will cancel the WAIT timer. Regarding test suites, you should always take the specification as the final word. At one point, I informed a very reputable test vendor (which will remain unnamed) that their OSPF database exchange test script was incorrect. Their response was that I didn't have a valid service contract - of course I wasn't WG co-chair at that time :^). Vishwas Manral wrote: >Hi, > >Though I am have not really followed the thread. > >For the question you raise either ways is ok. Though sending it immediately >helps in faster convergence. > >Thanks, >Vishwas > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor >Miroshnik >Sent: Thursday, November 06, 2003 4:21 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: UNH, interoperability, test OSPF-1.5c > > >Group, > >I am confused: > >On one hand Vivek insists the first Hello should not be issued before >HelloInterval elapses, on the other hand >John >http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0005&L=3Dospf&P=3DR43= 2&I=3D- 3 >and Alex >http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0006&L=3Dospf&D=3D0&I= =3D-3&P =3D3123 >mention immediate launch of Hello with InterfaceUp. >Please help to make up my mind. > >Thanks, >Igor > >On Thu, 6 Nov 2003 17:08:45 +0530, Vivek Gupta > wrote: > > > >>BackupSeen event will still not be raised, because on TR1 when Neighbor >>Change event occurs, DR election will still lead to election of RUT as >>BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain any >>change and hence no BACKUP SEEN event on RUT. >> >>Regards, >>Vivek >> >>-----Original Message----- >>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>Sent: Thursday, November 06, 2003 4:56 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: UNH, interoperability, test OSPF-1.5c >> >>Vivek, >> >>Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still >>notices that RUT is no longer declaring itself as BDR, thus raising >>NeighborChange event. The latter results in DR/BDR reelection and the >>next >>TR1's Hello (another HelloInterval-delay, at most) will indicate lack of >>BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again, >>20 >>seconds from RUT's comeback elapse, at most. >> >>Thanks you, >>Igor >> >>On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta >> wrote: >> >> >> >>>As per RFC, When the Interface comes up Hello Timer is >>>started.("Interface UP" event). >>> >>>That implies the HELLO packet will be sent by RUT 10 seconds after the >>>Interface came up. >>> >>>Therefore, when RUT comes up it can receive HELLO packet from TR1 >>> >>> >>before >> >> >>>it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till >>>say that BDR is "RUT"( because the change hasn't been detected by TR1 >>>till now). >>> >>>Now, at RUT no "Backupseen" event will be triggered and hence Wait >>> >>> >>timer >> >> >>>need to expire and it will take 40 seconds for RUT to declare itself as >>>BDR. >>> >>>Regards, >>>Vivek >>> >>>-----Original Message----- >>>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>>Sent: Thursday, November 06, 2003 3:51 PM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: UNH, interoperability, test OSPF-1.5c >>> >>>All, >>> >>>Please consider the following topology: >>> >>> +---+ | +---+ >>> |RUT|----|----|TR1| >>> +---+ | +---+ >>> Network 0 >>> >>>Part C: The RUT transitions to BDR >>> >>>10. Unplug the RUT's interface on network 0. >>>11. Reset OSPF. >>>12. Plug the RUT's interface back in on network 0 (TR1 should still >>> list RUT as BDR). >>>13. Observe the traffic transmitted on the network. >>> >>>Observable Results: >>> >>>In Part C, The RUT should wait for about 40 seconds before it >>>begins to claim itself to be the BDR on network 0. >>> >>> >>> >>>I wonder whether the result expected by the test are correct, since >>>the crucial part of it, the remark made within the parentheses in step >>>12, >>>cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR >>>respectively. When RUT is unplugged, reset (in OSPF context), and >>>plugged >>>again, it multicasts Hello listing no neighbors. TR1 notices loss of >>> >>> >>bi- >> >> >>>directional communication with RUT and reelects itself as DR leaving >>> >>> >>the >> >> >>>position of BDR vacant, while listing RUT as neighbor in the next >>>outgoing >>>Hello. RUT receives that Hello, establishes bi-directional >>> >>> >>communication >> >> >>>with TR1 (as it sees itself in the list), and discerns that TR1 claims >>>itself DR with no fellow BDR. Naturally, RUT reacts with the event >>>BackupSeen, running DR/BDR election ending up in the position of BDR. >>>The >>>entire procedure lasts from 1 to 20 seconds, which is below >>>RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary >>> >>> >>to >> >> >>>the results expected by the test. >>> >>>Thanks, >>>Igor >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Nov 9 10:01:53 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29965 for ; Sun, 9 Nov 2003 10:01: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 <0.00C3DC13@cherry.ease.lsoft.com>; 9 Nov 2003 10:02:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59917119 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 9 Nov 2003 10:02:00 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Nov 2003 10:02:00 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 09BDCA2104B for ; Sun, 9 Nov 2003 07:01:59 -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 00513-05 for ; Sun, 9 Nov 2003 07:01:58 -0800 (PST) Received: from redback.com (pptp-6-135.redback.com [155.53.6.135]) by prattle.redback.com (Postfix) with ESMTP id CC325A21049 for ; Sun, 9 Nov 2003 07:01:57 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <36993D449C7FA647BF43568E0793AB3E239981@nevis_pune_xchg.pune.nevisnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FAE56DA.8000907@redback.com> Date: Sun, 9 Nov 2003 10:01:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <36993D449C7FA647BF43568E0793AB3E239981@nevis_pune_xchg.pune.nevisnetworks.com> Precedence: list Content-Transfer-Encoding: 7bit Vivek Gupta wrote: >BackupSeen event will not be raised, because on TR1 when Neighbor >Change event occurs, DR election will lead to election of "RUT" as >BDR and "TR1" as DR. So, the Hello packet sent by TR1 will still contain > >"RUT" as TR1 and hence no BACKUP SEEN event on RUT will be triggered. > You are right for the case where RUT receives a hello from TR1 prior to sending its first hello. In the case where RUT sends a hello immediately upon the interface coming up, the DR election will not result in RUT being elected BDR since TR1 will not have bi-directionaly connectivity with RUT. If TR1 sends a hello with 0.0.0.0 as the BDR prior to receiving a hello from RUT with TR1 listed as an atttached router, RUT will get the BackupSeen event. In retrospect, it seems it would have made sense for the BackupSeen event to include the case where a router advertises your Router-ID as BDR. > >Regards, >Vivek > >-----Original Message----- >From: Acee Lindem [mailto:acee@REDBACK.COM] >Sent: Saturday, November 08, 2003 3:15 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: UNH, interoperability, test OSPF-1.5c > >In any case, I don't think the RUT should take RouterDeadInterval >seconds to get >the BackupSeen event and leave Wait state. I would think that once TR1 >receives a >hello from RUT, it will generate a NeigbborChange event and RUT will no >longer >be listed as BDR in TR1's helllos. This, in turn, will result in a >BackupSeen event (since >the TR1's BDR hello field is 0.0.0.0) on RUT and will cancel the WAIT >timer. > >Regarding test suites, you should always take the specification as the >final word. At >one point, I informed a very reputable test vendor (which will remain >unnamed) that >their OSPF database exchange test script was incorrect. Their response >was that I >didn't have a valid service contract - of course I wasn't WG co-chair at >that time :^). > >Vishwas Manral wrote: > > > >>Hi, >> >>Though I am have not really followed the thread. >> >>For the question you raise either ways is ok. Though sending it >> >> >immediately > > >>helps in faster convergence. >> >>Thanks, >>Vishwas >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor >>Miroshnik >>Sent: Thursday, November 06, 2003 4:21 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: UNH, interoperability, test OSPF-1.5c >> >> >>Group, >> >>I am confused: >> >>On one hand Vivek insists the first Hello should not be issued before >>HelloInterval elapses, on the other hand >>John >>http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0005&L=ospf&P=R432&I=- >> >> >3 > > >>and Alex >>http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0006&L=ospf&D=0&I=-3&P >> >> >=3123 > > >>mention immediate launch of Hello with InterfaceUp. >>Please help to make up my mind. >> >>Thanks, >>Igor >> >>On Thu, 6 Nov 2003 17:08:45 +0530, Vivek Gupta >> wrote: >> >> >> >> >> >>>BackupSeen event will still not be raised, because on TR1 when >>> >>> >Neighbor > > >>>Change event occurs, DR election will still lead to election of RUT as >>>BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain >>> >>> >any > > >>>change and hence no BACKUP SEEN event on RUT. >>> >>>Regards, >>>Vivek >>> >>>-----Original Message----- >>>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>>Sent: Thursday, November 06, 2003 4:56 PM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: Re: UNH, interoperability, test OSPF-1.5c >>> >>>Vivek, >>> >>>Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still >>>notices that RUT is no longer declaring itself as BDR, thus raising >>>NeighborChange event. The latter results in DR/BDR reelection and the >>>next >>>TR1's Hello (another HelloInterval-delay, at most) will indicate lack >>> >>> >of > > >>>BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. >>> >>> >Again, > > >>>20 >>>seconds from RUT's comeback elapse, at most. >>> >>>Thanks you, >>>Igor >>> >>>On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta >>> wrote: >>> >>> >>> >>> >>> >>>>As per RFC, When the Interface comes up Hello Timer is >>>>started.("Interface UP" event). >>>> >>>>That implies the HELLO packet will be sent by RUT 10 seconds after >>>> >>>> >the > > >>>>Interface came up. >>>> >>>>Therefore, when RUT comes up it can receive HELLO packet from TR1 >>>> >>>> >>>> >>>> >>>before >>> >>> >>> >>> >>>>it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will >>>> >>>> >till > > >>>>say that BDR is "RUT"( because the change hasn't been detected by TR1 >>>>till now). >>>> >>>>Now, at RUT no "Backupseen" event will be triggered and hence Wait >>>> >>>> >>>> >>>> >>>timer >>> >>> >>> >>> >>>>need to expire and it will take 40 seconds for RUT to declare itself >>>> >>>> >as > > >>>>BDR. >>>> >>>>Regards, >>>>Vivek >>>> >>>>-----Original Message----- >>>>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] >>>>Sent: Thursday, November 06, 2003 3:51 PM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: UNH, interoperability, test OSPF-1.5c >>>> >>>>All, >>>> >>>>Please consider the following topology: >>>> >>>> +---+ | +---+ >>>> |RUT|----|----|TR1| >>>> +---+ | +---+ >>>> Network 0 >>>> >>>>Part C: The RUT transitions to BDR >>>> >>>>10. Unplug the RUT's interface on network 0. >>>>11. Reset OSPF. >>>>12. Plug the RUT's interface back in on network 0 (TR1 should still >>>> list RUT as BDR). >>>>13. Observe the traffic transmitted on the network. >>>> >>>>Observable Results: >>>> >>>>In Part C, The RUT should wait for about 40 seconds before it >>>>begins to claim itself to be the BDR on network 0. >>>> >>>> >>>> >>>>I wonder whether the result expected by the test are correct, since >>>>the crucial part of it, the remark made within the parentheses in >>>> >>>> >step > > >>>>12, >>>>cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR >>>>respectively. When RUT is unplugged, reset (in OSPF context), and >>>>plugged >>>>again, it multicasts Hello listing no neighbors. TR1 notices loss of >>>> >>>> >>>> >>>> >>>bi- >>> >>> >>> >>> >>>>directional communication with RUT and reelects itself as DR leaving >>>> >>>> >>>> >>>> >>>the >>> >>> >>> >>> >>>>position of BDR vacant, while listing RUT as neighbor in the next >>>>outgoing >>>>Hello. RUT receives that Hello, establishes bi-directional >>>> >>>> >>>> >>>> >>>communication >>> >>> >>> >>> >>>>with TR1 (as it sees itself in the list), and discerns that TR1 >>>> >>>> >claims > > >>>>itself DR with no fellow BDR. Naturally, RUT reacts with the event >>>>BackupSeen, running DR/BDR election ending up in the position of BDR. >>>>The >>>>entire procedure lasts from 1 to 20 seconds, which is below >>>>RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary >>>> >>>> >>>> >>>> >>>to >>> >>> >>> >>> >>>>the results expected by the test. >>>> >>>>Thanks, >>>>Igor >>>> >>>> >>>> >>>> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Nov 9 15:15:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09007 for ; Sun, 9 Nov 2003 15:15:25 -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.00C3DDF6@cherry.ease.lsoft.com>; 9 Nov 2003 15:15:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59927489 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 9 Nov 2003 15:15:35 -0500 Received: from 207.217.120.126 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Nov 2003 15:15:34 -0400 Received: from user-38ldt29.dialup.mindspring.com ([209.86.244.73] helo=earthlink.net) by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AIvy7-00059L-00 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 09 Nov 2003 12:15:31 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <36993D449C7FA647BF43568E0793AB3E239981@nevis_pune_xchg.pune.nevisnetworks.com> <3FAE56DA.8000907@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3FAEA093.4924B39A@earthlink.net> Date: Sun, 9 Nov 2003 12:16:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: UNH, interoperability, test OSPF-1.5c To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Guys, I agree, but the bottom line. Do we have anybody on this mail alias who is part of the Univ of New Hampshire (UNH) OSPF test group AND believes that discussions like this warrant changes in their OSPF tests? And should each UNH test "be well documented to explain" the expected behaviour of a RUT. Mitchell Erblich Sr Software Engineer ------------------------------- Acee Lindem wrote: > > Vivek Gupta wrote: > > >BackupSeen event will not be raised, because on TR1 when Neighbor > >Change event occurs, DR election will lead to election of "RUT" as > >BDR and "TR1" as DR. So, the Hello packet sent by TR1 will still contain > > > >"RUT" as TR1 and hence no BACKUP SEEN event on RUT will be triggered. > > > You are right for the case where RUT receives a hello from TR1 prior to > sending its first hello. > In the case where RUT sends a hello immediately upon the interface > coming up, the DR > election will not result in RUT being elected BDR since TR1 will not > have bi-directionaly > connectivity with RUT. If TR1 sends a hello with 0.0.0.0 as the BDR > prior to > receiving a hello from RUT with TR1 listed as an atttached router, > RUT will get > the BackupSeen event. > > In retrospect, it seems it would have made sense for the BackupSeen > event to include > the case where a router advertises your Router-ID as BDR. > > > > >Regards, > >Vivek > > > >-----Original Message----- > >From: Acee Lindem [mailto:acee@REDBACK.COM] > >Sent: Saturday, November 08, 2003 3:15 AM > >To: OSPF@PEACH.EASE.LSOFT.COM > >Subject: Re: UNH, interoperability, test OSPF-1.5c > > > >In any case, I don't think the RUT should take RouterDeadInterval > >seconds to get > >the BackupSeen event and leave Wait state. I would think that once TR1 > >receives a > >hello from RUT, it will generate a NeigbborChange event and RUT will no > >longer > >be listed as BDR in TR1's helllos. This, in turn, will result in a > >BackupSeen event (since > >the TR1's BDR hello field is 0.0.0.0) on RUT and will cancel the WAIT > >timer. > > > >Regarding test suites, you should always take the specification as the > >final word. At > >one point, I informed a very reputable test vendor (which will remain > >unnamed) that > >their OSPF database exchange test script was incorrect. Their response > >was that I > >didn't have a valid service contract - of course I wasn't WG co-chair at > >that time :^). > > > >Vishwas Manral wrote: > > > > > > > >>Hi, > >> > >>Though I am have not really followed the thread. > >> > >>For the question you raise either ways is ok. Though sending it > >> > >> > >immediately > > > > > >>helps in faster convergence. > >> > >>Thanks, > >>Vishwas > >> > >> > >>-----Original Message----- > >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor > >>Miroshnik > >>Sent: Thursday, November 06, 2003 4:21 PM > >>To: OSPF@PEACH.EASE.LSOFT.COM > >>Subject: Re: UNH, interoperability, test OSPF-1.5c > >> > >> > >>Group, > >> > >>I am confused: > >> > >>On one hand Vivek insists the first Hello should not be issued before > >>HelloInterval elapses, on the other hand > >>John > >>http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0005&L=ospf&P=R432&I=- > >> > >> > >3 > > > > > >>and Alex > >>http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0006&L=ospf&D=0&I=-3&P > >> > >> > >=3123 > > > > > >>mention immediate launch of Hello with InterfaceUp. > >>Please help to make up my mind. > >> > >>Thanks, > >>Igor > >> > >>On Thu, 6 Nov 2003 17:08:45 +0530, Vivek Gupta > >> wrote: > >> > >> > >> > >> > >> > >>>BackupSeen event will still not be raised, because on TR1 when > >>> > >>> > >Neighbor > > > > > >>>Change event occurs, DR election will still lead to election of RUT as > >>>BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain > >>> > >>> > >any > > > > > >>>change and hence no BACKUP SEEN event on RUT. > >>> > >>>Regards, > >>>Vivek > >>> > >>>-----Original Message----- > >>>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] > >>>Sent: Thursday, November 06, 2003 4:56 PM > >>>To: OSPF@PEACH.EASE.LSOFT.COM > >>>Subject: Re: UNH, interoperability, test OSPF-1.5c > >>> > >>>Vivek, > >>> > >>>Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still > >>>notices that RUT is no longer declaring itself as BDR, thus raising > >>>NeighborChange event. The latter results in DR/BDR reelection and the > >>>next > >>>TR1's Hello (another HelloInterval-delay, at most) will indicate lack > >>> > >>> > >of > > > > > >>>BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. > >>> > >>> > >Again, > > > > > >>>20 > >>>seconds from RUT's comeback elapse, at most. > >>> > >>>Thanks you, > >>>Igor > >>> > >>>On Thu, 6 Nov 2003 16:13:13 +0530, Vivek Gupta > >>> wrote: > >>> > >>> > >>> > >>> > >>> > >>>>As per RFC, When the Interface comes up Hello Timer is > >>>>started.("Interface UP" event). > >>>> > >>>>That implies the HELLO packet will be sent by RUT 10 seconds after > >>>> > >>>> > >the > > > > > >>>>Interface came up. > >>>> > >>>>Therefore, when RUT comes up it can receive HELLO packet from TR1 > >>>> > >>>> > >>>> > >>>> > >>>before > >>> > >>> > >>> > >>> > >>>>it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will > >>>> > >>>> > >till > > > > > >>>>say that BDR is "RUT"( because the change hasn't been detected by TR1 > >>>>till now). > >>>> > >>>>Now, at RUT no "Backupseen" event will be triggered and hence Wait > >>>> > >>>> > >>>> > >>>> > >>>timer > >>> > >>> > >>> > >>> > >>>>need to expire and it will take 40 seconds for RUT to declare itself > >>>> > >>>> > >as > > > > > >>>>BDR. > >>>> > >>>>Regards, > >>>>Vivek > >>>> > >>>>-----Original Message----- > >>>>From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] > >>>>Sent: Thursday, November 06, 2003 3:51 PM > >>>>To: OSPF@PEACH.EASE.LSOFT.COM > >>>>Subject: UNH, interoperability, test OSPF-1.5c > >>>> > >>>>All, > >>>> > >>>>Please consider the following topology: > >>>> > >>>> +---+ | +---+ > >>>> |RUT|----|----|TR1| > >>>> +---+ | +---+ > >>>> Network 0 > >>>> > >>>>Part C: The RUT transitions to BDR > >>>> > >>>>10. Unplug the RUT's interface on network 0. > >>>>11. Reset OSPF. > >>>>12. Plug the RUT's interface back in on network 0 (TR1 should still > >>>> list RUT as BDR). > >>>>13. Observe the traffic transmitted on the network. > >>>> > >>>>Observable Results: > >>>> > >>>>In Part C, The RUT should wait for about 40 seconds before it > >>>>begins to claim itself to be the BDR on network 0. > >>>> > >>>> > >>>> > >>>>I wonder whether the result expected by the test are correct, since > >>>>the crucial part of it, the remark made within the parentheses in > >>>> > >>>> > >step > > > > > >>>>12, > >>>>cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR > >>>>respectively. When RUT is unplugged, reset (in OSPF context), and > >>>>plugged > >>>>again, it multicasts Hello listing no neighbors. TR1 notices loss of > >>>> > >>>> > >>>> > >>>> > >>>bi- > >>> > >>> > >>> > >>> > >>>>directional communication with RUT and reelects itself as DR leaving > >>>> > >>>> > >>>> > >>>> > >>>the > >>> > >>> > >>> > >>> > >>>>position of BDR vacant, while listing RUT as neighbor in the next > >>>>outgoing > >>>>Hello. RUT receives that Hello, establishes bi-directional > >>>> > >>>> > >>>> > >>>> > >>>communication > >>> > >>> > >>> > >>> > >>>>with TR1 (as it sees itself in the list), and discerns that TR1 > >>>> > >>>> > >claims > > > > > >>>>itself DR with no fellow BDR. Naturally, RUT reacts with the event > >>>>BackupSeen, running DR/BDR election ending up in the position of BDR. > >>>>The > >>>>entire procedure lasts from 1 to 20 seconds, which is below > >>>>RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary > >>>> > >>>> > >>>> > >>>> > >>>to > >>> > >>> > >>> > >>> > >>>>the results expected by the test. > >>>> > >>>>Thanks, > >>>>Igor > >>>> > >>>> > >>>> > >>>> > >> > >> > >> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 10 08:48:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19225 for ; Mon, 10 Nov 2003 08:48: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 <9.00C3ED8D@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 8:48:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60025619 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 08:48:14 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 08:48:14 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C3EEE7@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 8:48:13 -0500 Message-ID: Date: Mon, 10 Nov 2003 08:48:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Flushing Router LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Group, Suppose a router receives Router Links with MaxAge from an adjacent neighbor. Should it lose the adjacency with that neighbor? Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 10 09:00:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19769 for ; Mon, 10 Nov 2003 09:00: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 <15.00C3EEFF@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 9:00:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60026062 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 09:00:18 -0500 Received: from 61.95.163.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 09:00:18 -0400 Received: from vishwas ([192.168.10.115]) by localhost.localdomain (8.12.5/8.12.5) with SMTP id hAADt1To006719 for ; Mon, 10 Nov 2003 19:25:02 +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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Message-ID: <006401c3a7b0$ca86f230$730aa8c0@vishwas> Date: Mon, 10 Nov 2003 19:33:44 +0200 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Flushing Router LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Igor, I guess you mean MaxAged Router LSA when you say "Router Links with MaxAge". No, an adjacency does not need to be broken with the neighbor. The SPF will take care of the case and exclude the routers LSA's from its routing table calculation. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor Miroshnik Sent: Monday, November 10, 2003 3:48 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Flushing Router LSA Group, Suppose a router receives Router Links with MaxAge from an adjacent neighbor. Should it lose the adjacency with that neighbor? Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 10 11:59:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00121 for ; Mon, 10 Nov 2003 11:59: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 <22.00C3F2FA@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 11:59:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60042317 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:59:53 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 11:49:41 -0400 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAAGnfi17947 for ; Mon, 10 Nov 2003 08:49:41 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id hAAGneM85470 for ; Mon, 10 Nov 2003 08:49:41 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20031110084404.A84355@sapphire.juniper.net> Date: Mon, 10 Nov 2003 08:49:40 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F9EB8F2.10002@cisco.com> Precedence: list Following up on this thread, I have the following concerns with this document: 1. Tunnels are used both intra and inter domains. Thus tunnel capabilities have to be propagated across domains as well. Hence IGP is imho not appropriate for this application. 2. Tunnel capabilities are not used by core routeres. 3. There are existing documents that specify the use of BGP for this: draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt draft-nalawade-kapoor-tunnel-safi-01.txt Hence imho OSPF WG should not take on this work. Thanks, rahul On Tue, 28 Oct 2003, Robert Raszuk wrote: > Acee, > > > My biggest fear would be that if this draft is accepted it > > would only be the first of a torrent of auto-configuration > > drafts. > > Second one not first ;). Notice this one submitted a while back: > draft-raszuk-ospf-bgp-peer-discovery-00.txt > > > 1. Should OSPF be used for tunnel auto-configuration? > > I think in general this requires a study on a case by case basis. Most > important factors which should be taken into consideration are: > > *A* How frequently the information advertised changed - is it static > configuration or dynamic in nature which triggers reflooding ? > > *B* Is the application which the uses delivered information limited to > IGP domain or crosses domains ? > > *C* What is the amount of information to be flooded (keeping in mind > that majority of P routers - those in the core - will never use it. > > *D* What are the alternatives available & _deployed_ today to deliver > the same information to it's users > > *E* How often area wide flooding will be sufficient versus domain wide. > > Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the > following: > > Reg A: Info is essentially static except the L2TPv3 cookie rollover > intervals which if implementation permits could be changing periodically > > Reg B: I think that in any application of tunnels we can't limit the > scope of use to one IGP domain. There can be a lot of customers who may > never need to go over a domain (which this draft is targeting though). > > Reg C: Minimal (comparing to TE at least :):). > > Reg D: It is worth noting that there is a few drafts in IDR describing > the ideas for the same information distribution > > Reg E: Looking at the most common OSPF topologies I would say that most > tunnels will be build between edge PEs and those in a lot of cases are > located in it's own POP areas. Not to say that there are no customers > who keep most of their PEs on the edges of area 0. > > Rgs, > R. > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 10 15:47:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12787 for ; Mon, 10 Nov 2003 15:47: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 <22.00C3F87B@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 15:47:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60064882 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 15:47:36 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 15:47:36 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 12:50:52 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAAKlXrX016041; Mon, 10 Nov 2003 12:47:33 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-97.cisco.com [10.86.240.97]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK68531; Mon, 10 Nov 2003 12:47:31 -0800 (PST) X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3FAFF964.C21CB274@cisco.com> Date: Mon, 10 Nov 2003 12:47:32 -0800 Reply-To: Mailing List Sender: Mailing List From: Gargi Nalawade Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Comments: cc: swkeng@cisco.com, ppsenak@cisco.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Rahul, Thanks for your comments. Rahul Aggarwal wrote: > > Following up on this thread, I have the following concerns with this > document: > > 1. Tunnels are used both intra and inter domains. Thus tunnel Not always. There are tunnels which are purely intra-domain as well. > capabilities have to be propagated across domains as well. Hence IGP is > imho not appropriate for this application. > > 2. Tunnel capabilities are not used by core routeres. > > 3. There are existing documents that specify the use of BGP for this: > draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt > draft-nalawade-kapoor-tunnel-safi-01.txt The above BGP solutions can be used only in BGP networks. There are BGP-free networks that require tunneling Capabilities as well and we are receiving requests from those customers to provide a complementary solution that does not rely on BGP being present. Also - for the 2 specific drafts mentioned above, BGP uses the routes learnt through an IGP to resolve the nexthop to BGP prefixes. But in the presence of tunnels, this reachability is not sufficient and the reachability via the tunnels has to be propagated as well. The BGP solution has been created purely for the inter-Provider case where there is no inter-AS mechanism other than BGP to propagate that. But within a given network, when the tunnels are required only within an AS or domain, the IGP provides the reachability to the Tunnel end-point and hence is the right place to carry the tunnel reachability information as well. > Hence imho OSPF WG should not take on this work. Hence I believe that the IGP is the right place to carry the above and IMHO, the OSPF WG should take on this work. Thanks, Gargi > > Thanks, > rahul > > On Tue, 28 Oct 2003, Robert Raszuk wrote: > > > Acee, > > > > > My biggest fear would be that if this draft is accepted it > > > would only be the first of a torrent of auto-configuration > > > drafts. > > > > Second one not first ;). Notice this one submitted a while back: > > draft-raszuk-ospf-bgp-peer-discovery-00.txt > > > > > 1. Should OSPF be used for tunnel auto-configuration? > > > > I think in general this requires a study on a case by case basis. Most > > important factors which should be taken into consideration are: > > > > *A* How frequently the information advertised changed - is it static > > configuration or dynamic in nature which triggers reflooding ? > > > > *B* Is the application which the uses delivered information limited to > > IGP domain or crosses domains ? > > > > *C* What is the amount of information to be flooded (keeping in mind > > that majority of P routers - those in the core - will never use it. > > > > *D* What are the alternatives available & _deployed_ today to deliver > > the same information to it's users > > > > *E* How often area wide flooding will be sufficient versus domain wide. > > > > Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the > > following: > > > > Reg A: Info is essentially static except the L2TPv3 cookie rollover > > intervals which if implementation permits could be changing periodically > > > > Reg B: I think that in any application of tunnels we can't limit the > > scope of use to one IGP domain. There can be a lot of customers who may > > never need to go over a domain (which this draft is targeting though). > > > > Reg C: Minimal (comparing to TE at least :):). > > > > Reg D: It is worth noting that there is a few drafts in IDR describing > > the ideas for the same information distribution > > > > Reg E: Looking at the most common OSPF topologies I would say that most > > tunnels will be build between edge PEs and those in a lot of cases are > > located in it's own POP areas. Not to say that there are no customers > > who keep most of their PEs on the edges of area 0. > > > > Rgs, > > R. > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 10 15:58:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13243 for ; Mon, 10 Nov 2003 15:58: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 <4.00C3F89A@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 15:58:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60065383 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 15:58:25 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 15:58:24 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAAKwLmU016915; Mon, 10 Nov 2003 12:58:22 -0800 (PST) Received: from cisco.com (rtp-vpn2-310.cisco.com [10.82.241.54]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOB66319; Mon, 10 Nov 2003 12:58:20 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FAFFBEC.7090409@cisco.com> Date: Mon, 10 Nov 2003 12:58:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Comments: cc: Gargi Nalawade , Peter Psenak To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rahul, Rahul Aggarwal wrote: > Following up on this thread, I have the following concerns with this > document: > > 1. Tunnels are used both intra and inter domains. Thus tunnel > capabilities have to be propagated across domains as well. Hence IGP is > imho not appropriate for this application. > > 2. Tunnel capabilities are not used by core routeres. As we are announcing specific router capabilities, it therefore infers that only certain routers in the network are capable of some specific capabilities. If all routers in a network have the same capability, there is then no need for specific announcement. Thanks, Sandy > > 3. There are existing documents that specify the use of BGP for this: > draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt > draft-nalawade-kapoor-tunnel-safi-01.txt > > Hence imho OSPF WG should not take on this work. > > Thanks, > rahul > > On Tue, 28 Oct 2003, Robert Raszuk wrote: > > >>Acee, >> >> >>> My biggest fear would be that if this draft is accepted it >>> would only be the first of a torrent of auto-configuration >>> drafts. >> >>Second one not first ;). Notice this one submitted a while back: >>draft-raszuk-ospf-bgp-peer-discovery-00.txt >> >> > 1. Should OSPF be used for tunnel auto-configuration? >> >>I think in general this requires a study on a case by case basis. Most >>important factors which should be taken into consideration are: >> >>*A* How frequently the information advertised changed - is it static >>configuration or dynamic in nature which triggers reflooding ? >> >>*B* Is the application which the uses delivered information limited to >>IGP domain or crosses domains ? >> >>*C* What is the amount of information to be flooded (keeping in mind >>that majority of P routers - those in the core - will never use it. >> >>*D* What are the alternatives available & _deployed_ today to deliver >>the same information to it's users >> >>*E* How often area wide flooding will be sufficient versus domain wide. >> >>Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the >>following: >> >>Reg A: Info is essentially static except the L2TPv3 cookie rollover >>intervals which if implementation permits could be changing periodically >> >>Reg B: I think that in any application of tunnels we can't limit the >>scope of use to one IGP domain. There can be a lot of customers who may >>never need to go over a domain (which this draft is targeting though). >> >>Reg C: Minimal (comparing to TE at least :):). >> >>Reg D: It is worth noting that there is a few drafts in IDR describing >>the ideas for the same information distribution >> >>Reg E: Looking at the most common OSPF topologies I would say that most >>tunnels will be build between edge PEs and those in a lot of cases are >>located in it's own POP areas. Not to say that there are no customers >>who keep most of their PEs on the edges of area 0. >> >>Rgs, >>R. >> > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 10 16:12:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13796 for ; Mon, 10 Nov 2003 16:12:00 -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.00C3F819@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 16:12:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60066629 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 16:12:10 -0500 Received: from 208.45.178.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 16:12:10 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAALC9lf002033 for ; Mon, 10 Nov 2003 16:12:09 -0500 (EST) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Mon, 10 Nov 2003 16:12:02 -0500 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 16:12:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8A2FD2AE4BFC974481522E9D7943DCCB3246D5@sonusdc3.sonusnet.com> Date: Mon, 10 Nov 2003 16:12:01 -0500 Reply-To: Mailing List Sender: Mailing List From: "Sastry, Ravi" Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Any MTU issues especially when there are large number of tunnels? Just wondering.. ravi/ > -----Original Message----- > From: Sandy Eng [mailto:swkeng@CISCO.COM] > Sent: Monday, November 10, 2003 3:58 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt > > > Rahul, > > Rahul Aggarwal wrote: > > Following up on this thread, I have the following concerns with this > > document: > > > > 1. Tunnels are used both intra and inter domains. Thus tunnel > > capabilities have to be propagated across domains as well. > Hence IGP is > > imho not appropriate for this application. > > > > 2. Tunnel capabilities are not used by core routeres. > > As we are announcing specific router capabilities, it therefore infers > that only certain routers in the network are capable of some specific > capabilities. If all routers in a network have the same capability, > there is then no need for specific announcement. > > Thanks, > Sandy > > > > > > > 3. There are existing documents that specify the use of BGP > for this: > > draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt > > draft-nalawade-kapoor-tunnel-safi-01.txt > > > > Hence imho OSPF WG should not take on this work. > > > > Thanks, > > rahul > > > > On Tue, 28 Oct 2003, Robert Raszuk wrote: > > > > > >>Acee, > >> > >> > >>> My biggest fear would be that if this draft is accepted it > >>> would only be the first of a torrent of auto-configuration > >>> drafts. > >> > >>Second one not first ;). Notice this one submitted a while back: > >>draft-raszuk-ospf-bgp-peer-discovery-00.txt > >> > >> > 1. Should OSPF be used for tunnel auto-configuration? > >> > >>I think in general this requires a study on a case by case > basis. Most > >>important factors which should be taken into consideration are: > >> > >>*A* How frequently the information advertised changed - is it static > >>configuration or dynamic in nature which triggers reflooding ? > >> > >>*B* Is the application which the uses delivered information > limited to > >>IGP domain or crosses domains ? > >> > >>*C* What is the amount of information to be flooded (keeping in mind > >>that majority of P routers - those in the core - will never use it. > >> > >>*D* What are the alternatives available & _deployed_ today > to deliver > >>the same information to it's users > >> > >>*E* How often area wide flooding will be sufficient versus > domain wide. > >> > >>Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the > >>following: > >> > >>Reg A: Info is essentially static except the L2TPv3 cookie rollover > >>intervals which if implementation permits could be changing > periodically > >> > >>Reg B: I think that in any application of tunnels we can't limit the > >>scope of use to one IGP domain. There can be a lot of > customers who may > >>never need to go over a domain (which this draft is > targeting though). > >> > >>Reg C: Minimal (comparing to TE at least :):). > >> > >>Reg D: It is worth noting that there is a few drafts in IDR > describing > >>the ideas for the same information distribution > >> > >>Reg E: Looking at the most common OSPF topologies I would > say that most > >>tunnels will be build between edge PEs and those in a lot > of cases are > >>located in it's own POP areas. Not to say that there are no > customers > >>who keep most of their PEs on the edges of area 0. > >> > >>Rgs, > >>R. > >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 10 16:36:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14659 for ; Mon, 10 Nov 2003 16:36: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 <2.00C3F9D3@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 16:36:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60068212 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 16:36:32 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 16:36:32 -0400 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAALaTw5001832; Mon, 10 Nov 2003 13:36:30 -0800 (PST) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA27590; Mon, 10 Nov 2003 13:36:29 -0800 (PST) Message-ID: <200311102136.NAA27590@irp-view7.cisco.com> Date: Mon, 10 Nov 2003 13:36:29 -0800 Reply-To: Mailing List Sender: Mailing List From: fred@CISCO.COM Subject: Baker slides on Manet OSPF Comments: To: manet@ietf.org, proceedings@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list You may find the slides I'm using in OSPF and in Manet at: ftp://ftpeng.cisco.com/fred/manet/Problem_Statement_for_OSPF_Extensions_for_Mobile_Ad.pdf ftp://ftpeng.cisco.com/fred/manet/Problem_Statement_for_OSPF_Extensions_for_Mobile_Ad.ppt From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 10 17:45:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18679 for ; Mon, 10 Nov 2003 17:45: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 <6.00C3FBAD@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 17:45:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60073620 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 17:45:42 -0500 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 17:45:42 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C3FA6D@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 17:45:42 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 17:45:42 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJKmz-0000l4-DF for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Nov 2003 22:45:41 +0000 X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19899595280.20031110164510@psg.com> Date: Mon, 10 Nov 2003 16:45:10 -0600 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: My comment on draft-mirtorabi-ospf-tunnel-adjacency Comments: To: OSPF@DISCUSS.MICROSOFT.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Here's the question I asked at the mic today: 2328 limits the configuration of the VLs so that they can only transit through non-backbone areas and always belong to the backbone. Among other things this prevents "recursive" VLs, i.e., VLs relying on other VLs. The draft relaxes this and suggests that the TA can belong to any area and can transit any area. This opens up a possibility for TA1 that belongs to area A1 to transit area A2 that has TA2. This means that it could be possible for packets to be encapsulated more than once. It seems it could also be possible to have recursive TA resolution, e.g. in the case above, TA2 transiting area A1. Seems that this needs to be given more thought. -- Alex P.S. Padma also pointed out the possibility for excessive SPF calculation, but I'll leave it to her to describe the concern she has From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 11 06:28:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27389 for ; Tue, 11 Nov 2003 06:28: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 <12.00C40B17@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 6:29:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60148733 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 06:29:05 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 06:29:05 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2003 03:35:31 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hABBT2At006318 for ; Tue, 11 Nov 2003 03:29:03 -0800 (PST) Received: from cisco.com (rtp-vpn1-189.cisco.com [10.82.224.189]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOC26706; Tue, 11 Nov 2003 03:29:00 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8A2FD2AE4BFC974481522E9D7943DCCB3246D5@sonusdc3.sonusnet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FB0C7FA.1080206@cisco.com> Date: Tue, 11 Nov 2003 03:28:58 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ravi, Sastry, Ravi wrote: > Any MTU issues especially when there are large > number of tunnels? Just wondering.. OSPF relies on IP for fragmentation, there's no difference with this LSA. Thanks, Sandy > > > ravi/ > > > >>-----Original Message----- >>From: Sandy Eng [mailto:swkeng@CISCO.COM] >>Sent: Monday, November 10, 2003 3:58 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt >> >> >>Rahul, >> >>Rahul Aggarwal wrote: >> >>>Following up on this thread, I have the following concerns with this >>>document: >>> >>>1. Tunnels are used both intra and inter domains. Thus tunnel >>>capabilities have to be propagated across domains as well. >> >>Hence IGP is >> >>>imho not appropriate for this application. >>> >>>2. Tunnel capabilities are not used by core routeres. >> >>As we are announcing specific router capabilities, it therefore infers >>that only certain routers in the network are capable of some specific >>capabilities. If all routers in a network have the same capability, >>there is then no need for specific announcement. >> >>Thanks, >>Sandy >> >> >> >> >>>3. There are existing documents that specify the use of BGP >> >>for this: >> >>>draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt >>>draft-nalawade-kapoor-tunnel-safi-01.txt >>> >>>Hence imho OSPF WG should not take on this work. >>> >>>Thanks, >>>rahul >>> >>>On Tue, 28 Oct 2003, Robert Raszuk wrote: >>> >>> >>> >>>>Acee, >>>> >>>> >>>> >>>>> My biggest fear would be that if this draft is accepted it >>>>> would only be the first of a torrent of auto-configuration >>>>> drafts. >>>> >>>>Second one not first ;). Notice this one submitted a while back: >>>>draft-raszuk-ospf-bgp-peer-discovery-00.txt >>>> >>>> >>>>> 1. Should OSPF be used for tunnel auto-configuration? >>>> >>>>I think in general this requires a study on a case by case >>> >>basis. Most >> >>>>important factors which should be taken into consideration are: >>>> >>>>*A* How frequently the information advertised changed - is it static >>>>configuration or dynamic in nature which triggers reflooding ? >>>> >>>>*B* Is the application which the uses delivered information >>> >>limited to >> >>>>IGP domain or crosses domains ? >>>> >>>>*C* What is the amount of information to be flooded (keeping in mind >>>>that majority of P routers - those in the core - will never use it. >>>> >>>>*D* What are the alternatives available & _deployed_ today >>> >>to deliver >> >>>>the same information to it's users >>>> >>>>*E* How often area wide flooding will be sufficient versus >>> >>domain wide. >> >>>>Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the >>>>following: >>>> >>>>Reg A: Info is essentially static except the L2TPv3 cookie rollover >>>>intervals which if implementation permits could be changing >>> >>periodically >> >>>>Reg B: I think that in any application of tunnels we can't limit the >>>>scope of use to one IGP domain. There can be a lot of >>> >>customers who may >> >>>>never need to go over a domain (which this draft is >>> >>targeting though). >> >>>>Reg C: Minimal (comparing to TE at least :):). >>>> >>>>Reg D: It is worth noting that there is a few drafts in IDR >>> >>describing >> >>>>the ideas for the same information distribution >>>> >>>>Reg E: Looking at the most common OSPF topologies I would >>> >>say that most >> >>>>tunnels will be build between edge PEs and those in a lot >>> >>of cases are >> >>>>located in it's own POP areas. Not to say that there are no >>> >>customers >> >>>>who keep most of their PEs on the edges of area 0. >>>> >>>>Rgs, >>>>R. >>>> >>> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 11 10:55:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06910 for ; Tue, 11 Nov 2003 10:55: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 <2.00C41008@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 10:55:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60168242 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 10:55:31 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 10:55:31 -0400 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hABFtSxg022339 for ; Tue, 11 Nov 2003 10:55:28 -0500 (EST) Received: from pauwellsw2k (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id JAA28116; Tue, 11 Nov 2003 09:55:27 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <003f01c3a86c$366d1a40$01868182@amer.cisco.com> Date: Tue, 11 Nov 2003 09:55:20 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Comment on draft-mirtorabi-ospfv3-af-alt-00 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I'd like to propose a minor change to the instance range values that this draft uses to differentiate between address families. Since the size of these ranges seems fairly arbitrary, I'd suggest that we choose a power of two (say 32) rather than the current value of 20. This would change section 3 of the draft to: Instance ID # 0 - # 31 IPv6 unicast AF Instance ID # 32 - # 63 IPv6 multicast AF Instance ID # 64 - # 95 IPv4 unicast AF Instance ID # 96 - # 127 IPv4 multicast AF Instance ID # 128 - # 255 Reserved This seems more consistent with the way most protocol fields are defined, and gives implementers the additional option of using bit-wise operators when demuxing the incoming packets. - Paul Wells From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 11 14:20:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16224 for ; Tue, 11 Nov 2003 14:20: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 <18.00C411FE@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 14:20:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60182325 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 14:20:40 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 14:20:39 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 11:24:14 -0800 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABJKaDM018236 for ; Tue, 11 Nov 2003 14:20:36 -0500 (EST) Received: from pauwellsw2k (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id NAA15562; Tue, 11 Nov 2003 13:20:34 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <004c01c3a888$ddebe9b0$a9418182@amer.cisco.com> Date: Tue, 11 Nov 2003 13:20:27 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit A concern I have with the current version of draft-ietf-ospf-ospfv3-auth is that it does not specify a method for rekeying an authenticated OSPFv3 link without breaking the adjacency. In practice, I think such a mechanism will be needed for the following reasons: 1. The security provided by a static key decreases with time. The experience of 802.11 static WEP keys is one example of this. 2. Our customers aren't going to like a solution that requires even brief outages for periodic rekeying. Non-disruptive re-keying of a link should be possible by establishing an additional input SA with the new key. Once all the routers on a link have done this, the transmit SAs can be moved over. Finally, once all the routers have moved to the new key, the old input SAs can be removed. The trick will be in reliably controlling and synchronizing this sequence. If this is a problem that we're going to solve, I'd suggest that putting it into the draft, at least as a "SHOULD", will make it more likely that implementations will interoperate. Thanks. - Paul Wells From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 11 23:08:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06879 for ; Tue, 11 Nov 2003 23:08: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 <23.00C41F41@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 23:08:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60220139 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 23:07:35 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 23:07:35 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F20EEC73C0 for ; Tue, 11 Nov 2003 20:07:34 -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 17859-06 for ; Tue, 11 Nov 2003 20:07:34 -0800 (PST) Received: from redback.com (pptp-6-142.redback.com [155.53.6.142]) by prattle.redback.com (Postfix) with ESMTP id 82BD0C73CD for ; Tue, 11 Nov 2003 20:07:34 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <004c01c3a888$ddebe9b0$a9418182@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FB1B1FC.7050605@redback.com> Date: Tue, 11 Nov 2003 23:07:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <004c01c3a888$ddebe9b0$a9418182@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Paul Wells wrote: >A concern I have with the current version of draft-ietf-ospf-ospfv3-auth is >that it does not specify a method for rekeying an authenticated OSPFv3 link >without breaking the adjacency. In practice, I think such a mechanism will >be needed for the following reasons: > >1. The security provided by a static key decreases with time. The >experience of 802.11 static WEP keys is one example of this. > >2. Our customers aren't going to like a solution that requires even brief >outages for periodic rekeying. > >Non-disruptive re-keying of a link should be possible by establishing an >additional input SA with the new key. Once all the routers on a link have >done this, the transmit SAs can be moved over. Finally, once all the >routers have moved to the new key, the old input SAs can be removed. > This is a good point - I also think this should be included in the draft. >The >trick will be in reliably controlling and synchronizing this sequence. > Not sure that this should be specified - it has typically been implementation specific. > >If this is a problem that we're going to solve, I'd suggest that putting it >into the draft, at least as a "SHOULD", will make it more likely that >implementations will interoperate. > >Thanks. > >- Paul Wells > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 11 23:34:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07369 for ; Tue, 11 Nov 2003 23:34: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 <12.00C41F66@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 23:34:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60223335 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 23:34:44 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 23:34:44 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAC4Yhs24034 for ; Wed, 12 Nov 2003 06:34:43 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Nov 2003 06:34:43 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 22:34:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 Thread-Index: AcOoiPWxnPPfaTTGQW2HhThGbUb0gwATFSmw X-OriginalArrivalTime: 12 Nov 2003 04:34:41.0958 (UTC) FILETIME=[4A4DB460:01C3A8D6] Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABDF1@daebe009.americas.nokia.com> Date: Tue, 11 Nov 2003 22:34:39 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Paul, I am happy to receive some comments on the draft :) I am just wondering about why you think that re-keying will always break the adjacency ? As the whole authentication process is transparent to OSPF, the only thing that OSPF will see is some missing packets=20 (hello packets in a stable situation). If the keys are changed within say 1 minute on all the routers that are on a common link (how many ospf routers are gonna be there on a common link ??), the adjacency won't break. Right ? Moreover, if a customer wants to change the keys periodically, he/she might not choose to do it manaully everytime. And if=20 they do it with some automated way, 1 minute should be more=20 than enough to change keys on all the routers. So why do you think that it will break the adjacency ?? Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Paul Wells > Sent: Tuesday, November 11, 2003 1:20 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 >=20 >=20 > A concern I have with the current version of=20 > draft-ietf-ospf-ospfv3-auth is > that it does not specify a method for rekeying an=20 > authenticated OSPFv3 link > without breaking the adjacency. In practice, I think such a=20 > mechanism will > be needed for the following reasons: >=20 > 1. The security provided by a static key decreases with time. The > experience of 802.11 static WEP keys is one example of this. >=20 > 2. Our customers aren't going to like a solution that=20 > requires even brief > outages for periodic rekeying. >=20 > Non-disruptive re-keying of a link should be possible by=20 > establishing an > additional input SA with the new key. Once all the routers=20 > on a link have > done this, the transmit SAs can be moved over. Finally, once all the > routers have moved to the new key, the old input SAs can be=20 > removed. The > trick will be in reliably controlling and synchronizing this sequence. >=20 > If this is a problem that we're going to solve, I'd suggest=20 > that putting it > into the draft, at least as a "SHOULD", will make it more likely that > implementations will interoperate. >=20 > Thanks. >=20 > - Paul Wells >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 11 23:52:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07759 for ; Tue, 11 Nov 2003 23:52: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 <14.00C41F11@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 23:52:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60225271 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 23:52:48 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 23:52:48 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F2112857D43 for ; Tue, 11 Nov 2003 20:52:46 -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 24240-01 for ; Tue, 11 Nov 2003 20:52:46 -0800 (PST) Received: from redback.com (pptp-6-142.redback.com [155.53.6.142]) by prattle.redback.com (Postfix) with ESMTP id 11818857D40 for ; Tue, 11 Nov 2003 20:52:46 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA42ABDF1@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FB1BC93.3060200@redback.com> Date: Tue, 11 Nov 2003 23:52:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABDF1@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh.Gupta@NOKIA.COM wrote: >Paul, > >I am happy to receive some comments on the draft :) > >I am just wondering about why you think that re-keying will >always break the adjacency ? > >As the whole authentication process is transparent to OSPF, >the only thing that OSPF will see is some missing packets >(hello packets in a stable situation). If the keys are changed >within say 1 minute on all the routers that are on a common >link (how many ospf routers are gonna be there on a common >link ??), the adjacency won't break. Right ? > I believe it is configured dead interval (which can be as small as 2 seconds using base OSPF or 1 second using some tricks). > >Moreover, if a customer wants to change the keys periodically, >he/she might not choose to do it manaully everytime. And if >they do it with some automated way, 1 minute should be more >than enough to change keys on all the routers. > >So why do you think that it will break the adjacency ?? > >Regards >Mukesh > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext >>Paul Wells >>Sent: Tuesday, November 11, 2003 1:20 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 >> >> >>A concern I have with the current version of >>draft-ietf-ospf-ospfv3-auth is >>that it does not specify a method for rekeying an >>authenticated OSPFv3 link >>without breaking the adjacency. In practice, I think such a >>mechanism will >>be needed for the following reasons: >> >>1. The security provided by a static key decreases with time. The >>experience of 802.11 static WEP keys is one example of this. >> >>2. Our customers aren't going to like a solution that >>requires even brief >>outages for periodic rekeying. >> >>Non-disruptive re-keying of a link should be possible by >>establishing an >>additional input SA with the new key. Once all the routers >>on a link have >>done this, the transmit SAs can be moved over. Finally, once all the >>routers have moved to the new key, the old input SAs can be >>removed. The >>trick will be in reliably controlling and synchronizing this sequence. >> >>If this is a problem that we're going to solve, I'd suggest >>that putting it >>into the draft, at least as a "SHOULD", will make it more likely that >>implementations will interoperate. >> >>Thanks. >> >>- Paul Wells >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 00:14:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08352 for ; Wed, 12 Nov 2003 00:14:50 -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.00C421AD@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 0:13:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60233311 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 00:13:50 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 00:13:50 -0400 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAC5Dni03144 for ; Tue, 11 Nov 2003 21:13:49 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id hAC5Dl616617 for ; Tue, 11 Nov 2003 21:13:49 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFF964.C21CB274@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20031111205413.D12111@sapphire.juniper.net> Date: Tue, 11 Nov 2003 21:13:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FAFF964.C21CB274@cisco.com> Precedence: list Hi Gargi, Sorry for the delay. Please see inline: > > Following up on this thread, I have the following concerns with this > > document: > > > > 1. Tunnels are used both intra and inter domains. Thus tunnel > > Not always. There are tunnels which are purely intra-domain as well. > The point is that one *has* to solve the inter-domain case. IGP cannot do that unlike BGP based solutions which do that. Given that why a different solution for the intra domain case ? Note that in a domain this information is needed only by the PEs. It doesn't need to be flooded on all the P routers. > > > > 2. Tunnel capabilities are not used by core routeres. > > > > 3. There are existing documents that specify the use of BGP for this: > > draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt > > draft-nalawade-kapoor-tunnel-safi-01.txt > > The above BGP solutions can be used only in BGP networks. There are > BGP-free networks that require tunneling Capabilities as well and we > are receiving requests from those customers to provide a complementary > solution that does not rely on BGP being present. > The core maybe BGP free, but the PE routers will run BGP. Can you explain the scenario when the PEs don't run BGP ? > Also - for the 2 specific drafts mentioned above, BGP uses the routes > learnt through an IGP to resolve the nexthop to BGP prefixes. But in > the presence of tunnels, this reachability is not sufficient and the > reachability via the tunnels has to be propagated as well. For route resolution, the BGP next-hop needs to be reachable. The BGP next-hop will be the tunnel endpoint address. This in turn will be an IGP route. Why is this not sufficient ? The BGP > solution has been created purely for the inter-Provider case where there > is no inter-AS mechanism other than BGP to propagate that. But within > a given network, when the tunnels are required only within an AS or domain, > the IGP provides the reachability to the Tunnel end-point and hence is the > right place to carry the tunnel reachability information as well. > Then maybe IGPs should carry labelled VPN routes too in a domain ? Thanks, rahul > > Hence imho OSPF WG should not take on this work. > > Hence I believe that the IGP is the right place to carry the above and > IMHO, the OSPF WG should take on this work. > > Thanks, > Gargi > > > > > Thanks, > > rahul > > > > On Tue, 28 Oct 2003, Robert Raszuk wrote: > > > > > Acee, > > > > > > > My biggest fear would be that if this draft is accepted it > > > > would only be the first of a torrent of auto-configuration > > > > drafts. > > > > > > Second one not first ;). Notice this one submitted a while back: > > > draft-raszuk-ospf-bgp-peer-discovery-00.txt > > > > > > > 1. Should OSPF be used for tunnel auto-configuration? > > > > > > I think in general this requires a study on a case by case basis. Most > > > important factors which should be taken into consideration are: > > > > > > *A* How frequently the information advertised changed - is it static > > > configuration or dynamic in nature which triggers reflooding ? > > > > > > *B* Is the application which the uses delivered information limited to > > > IGP domain or crosses domains ? > > > > > > *C* What is the amount of information to be flooded (keeping in mind > > > that majority of P routers - those in the core - will never use it. > > > > > > *D* What are the alternatives available & _deployed_ today to deliver > > > the same information to it's users > > > > > > *E* How often area wide flooding will be sufficient versus domain wide. > > > > > > Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the > > > following: > > > > > > Reg A: Info is essentially static except the L2TPv3 cookie rollover > > > intervals which if implementation permits could be changing periodically > > > > > > Reg B: I think that in any application of tunnels we can't limit the > > > scope of use to one IGP domain. There can be a lot of customers who may > > > never need to go over a domain (which this draft is targeting though). > > > > > > Reg C: Minimal (comparing to TE at least :):). > > > > > > Reg D: It is worth noting that there is a few drafts in IDR describing > > > the ideas for the same information distribution > > > > > > Reg E: Looking at the most common OSPF topologies I would say that most > > > tunnels will be build between edge PEs and those in a lot of cases are > > > located in it's own POP areas. Not to say that there are no customers > > > who keep most of their PEs on the edges of area 0. > > > > > > Rgs, > > > R. > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 00:16:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08383 for ; Wed, 12 Nov 2003 00:16: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 <16.00C4215A@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 0:16:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60234808 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 00:16:42 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 00:16:42 -0400 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAC5Gfi03377 for ; Tue, 11 Nov 2003 21:16:41 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id hAC5Gff16927 for ; Tue, 11 Nov 2003 21:16:41 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFFBEC.7090409@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20031111211412.Y12111@sapphire.juniper.net> Date: Tue, 11 Nov 2003 21:16:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FAFFBEC.7090409@cisco.com> Precedence: list Hi Sandy, On Mon, 10 Nov 2003, Sandy Eng wrote: > Rahul, > > Rahul Aggarwal wrote: > > Following up on this thread, I have the following concerns with this > > document: > > > > 1. Tunnels are used both intra and inter domains. Thus tunnel > > capabilities have to be propagated across domains as well. Hence IGP is > > imho not appropriate for this application. > > > > 2. Tunnel capabilities are not used by core routeres. > > As we are announcing specific router capabilities, it therefore infers > that only certain routers in the network are capable of some specific > capabilities. If all routers in a network have the same capability, > there is then no need for specific announcement. > The tunnel encapsulations are needed by the PE routers and are advertised by the PE routers. Different PE routers can advertise different tunnel capabailities. However P routers do not require this information. rahul > Thanks, > Sandy > > > > > > > 3. There are existing documents that specify the use of BGP for this: > > draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt > > draft-nalawade-kapoor-tunnel-safi-01.txt > > > > Hence imho OSPF WG should not take on this work. > > > > Thanks, > > rahul > > > > On Tue, 28 Oct 2003, Robert Raszuk wrote: > > > > > >>Acee, > >> > >> > >>> My biggest fear would be that if this draft is accepted it > >>> would only be the first of a torrent of auto-configuration > >>> drafts. > >> > >>Second one not first ;). Notice this one submitted a while back: > >>draft-raszuk-ospf-bgp-peer-discovery-00.txt > >> > >> > 1. Should OSPF be used for tunnel auto-configuration? > >> > >>I think in general this requires a study on a case by case basis. Most > >>important factors which should be taken into consideration are: > >> > >>*A* How frequently the information advertised changed - is it static > >>configuration or dynamic in nature which triggers reflooding ? > >> > >>*B* Is the application which the uses delivered information limited to > >>IGP domain or crosses domains ? > >> > >>*C* What is the amount of information to be flooded (keeping in mind > >>that majority of P routers - those in the core - will never use it. > >> > >>*D* What are the alternatives available & _deployed_ today to deliver > >>the same information to it's users > >> > >>*E* How often area wide flooding will be sufficient versus domain wide. > >> > >>Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the > >>following: > >> > >>Reg A: Info is essentially static except the L2TPv3 cookie rollover > >>intervals which if implementation permits could be changing periodically > >> > >>Reg B: I think that in any application of tunnels we can't limit the > >>scope of use to one IGP domain. There can be a lot of customers who may > >>never need to go over a domain (which this draft is targeting though). > >> > >>Reg C: Minimal (comparing to TE at least :):). > >> > >>Reg D: It is worth noting that there is a few drafts in IDR describing > >>the ideas for the same information distribution > >> > >>Reg E: Looking at the most common OSPF topologies I would say that most > >>tunnels will be build between edge PEs and those in a lot of cases are > >>located in it's own POP areas. Not to say that there are no customers > >>who keep most of their PEs on the edges of area 0. > >> > >>Rgs, > >>R. > >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 00:49:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09500 for ; Wed, 12 Nov 2003 00:49: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 <7.00C42262@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 0:49:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60238810 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 00:49:21 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 00:49:21 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2003 21:56:02 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAC5nJmU026288 for ; Tue, 11 Nov 2003 21:49:19 -0800 (PST) Received: from cisco.com (rtp-vpn1-13.cisco.com [10.82.224.13]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANM27211; Tue, 11 Nov 2003 21:49:18 -0800 (PST) X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFF964.C21CB274@cisco.com> <20031111205413.D12111@sapphire.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3FB1C9DD.F4BA562B@cisco.com> Date: Tue, 11 Nov 2003 21:49:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Gargi Nalawade Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Rahul, Inline... Rahul Aggarwal wrote: > > Hi Gargi, > > Sorry for the delay. Please see inline: > > > > Following up on this thread, I have the following concerns with this > > > document: > > > > > > 1. Tunnels are used both intra and inter domains. Thus tunnel > > > > Not always. There are tunnels which are purely intra-domain as well. > > > > The point is that one *has* to solve the inter-domain case. IGP cannot > do that unlike BGP based solutions which do that. Given that why a By that argument why have anything that is in both BGP & IGP? Why have redistribution between protocols at all? :) The inter-AS - more expensive solution would be used when inter-AS tunnels are needed, whereas the intra-AS solution can be used in case of intra-AS tunnels and also if a Provider wants to propagate tunnel information within its domain using an IGP and redistribute only the inter-AS information on the border PEs. This completes the solution. These are not competing solutions. One complements and completes the other and caters to those customers who do not want to run BGP to signal these tunnel end-points and want to treat them (correctly) as part of IGP reachability. > different solution for the intra domain case ? Note that in a domain this > information is needed only by the PEs. It doesn't need to be flooded on > all the P routers. Not necessarily. Depends on the application. You are narrowing down the scope to a particular application - which is why you think PE. I agree that common scenarios would be PE-to-PE. But that does not mean that there won't be scenarios that have P routers as endpoints. TE-tunnels is one example. Also note that this draft is a framework for tunnel endpoint signalling and how and where it is deployed/used and whether the tunnel endpoints are PEs or Ps depends on the specific application a Provider or an Enterprise has in mind. > > > > > > > 2. Tunnel capabilities are not used by core routeres. > > > > > > 3. There are existing documents that specify the use of BGP for this: > > > draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt > > > draft-nalawade-kapoor-tunnel-safi-01.txt > > > > The above BGP solutions can be used only in BGP networks. There are > > BGP-free networks that require tunneling Capabilities as well and we > > are receiving requests from those customers to provide a complementary > > solution that does not rely on BGP being present. > > > > The core maybe BGP free, but the PE routers will run BGP. Can you explain > the scenario when the PEs don't run BGP ? You are only thinking Provider VPNs. In that case yes - the PEs will run BGP. But like I said this is not limited to Provider VPNs and hence the tunnel endpoints could be just vanilla IGP routers. > > Also - for the 2 specific drafts mentioned above, BGP uses the routes > > learnt through an IGP to resolve the nexthop to BGP prefixes. But in > > the presence of tunnels, this reachability is not sufficient > and the > > reachability via the tunnels has to be propagated as well. > > For route resolution, the BGP next-hop needs to be reachable. The BGP > next-hop will be the tunnel endpoint address. This in turn will be an IGP > route. Why is this not sufficient ? Because the reachability would be through the tunnel. Unless the tunnel comes up - traffic cannot begin to flow through it and hence the destination is still unreachable as long as the Tunnel endpoint encapsulation is not received. That really belongs in the IGP which is what provides the reachability to the endpoint. > > The BGP > > solution has been created purely for the inter-Provider case where there > > is no inter-AS mechanism other than BGP to propagate that. But within > > a given network, when the tunnels are required only within an AS or domain, > > the IGP provides the reachability to the Tunnel end-point and hence is the > > right place to carry the tunnel reachability information as well. > > > > Then maybe IGPs should carry labelled VPN routes too in a domain ? Well, thats upto you, if you want to define that. ;-) I'm not the one saying that. Thanks, Gargi > > Thanks, > rahul > > > > Hence imho OSPF WG should not take on this work. > > > > Hence I believe that the IGP is the right place to carry the above and > > IMHO, the OSPF WG should take on this work. > > > > Thanks, > > Gargi > > > > > > > > Thanks, > > > rahul > > > > > > On Tue, 28 Oct 2003, Robert Raszuk wrote: > > > > > > > Acee, > > > > > > > > > My biggest fear would be that if this draft is accepted it > > > > > would only be the first of a torrent of auto-configuration > > > > > drafts. > > > > > > > > Second one not first ;). Notice this one submitted a while back: > > > > draft-raszuk-ospf-bgp-peer-discovery-00.txt > > > > > > > > > 1. Should OSPF be used for tunnel auto-configuration? > > > > > > > > I think in general this requires a study on a case by case basis. Most > > > > important factors which should be taken into consideration are: > > > > > > > > *A* How frequently the information advertised changed - is it static > > > > configuration or dynamic in nature which triggers reflooding ? > > > > > > > > *B* Is the application which the uses delivered information limited to > > > > IGP domain or crosses domains ? > > > > > > > > *C* What is the amount of information to be flooded (keeping in mind > > > > that majority of P routers - those in the core - will never use it. > > > > > > > > *D* What are the alternatives available & _deployed_ today to deliver > > > > the same information to it's users > > > > > > > > *E* How often area wide flooding will be sufficient versus domain wide. > > > > > > > > Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the > > > > following: > > > > > > > > Reg A: Info is essentially static except the L2TPv3 cookie rollover > > > > intervals which if implementation permits could be changing periodically > > > > > > > > Reg B: I think that in any application of tunnels we can't limit the > > > > scope of use to one IGP domain. There can be a lot of customers who may > > > > never need to go over a domain (which this draft is targeting though). > > > > > > > > Reg C: Minimal (comparing to TE at least :):). > > > > > > > > Reg D: It is worth noting that there is a few drafts in IDR describing > > > > the ideas for the same information distribution > > > > > > > > Reg E: Looking at the most common OSPF topologies I would say that most > > > > tunnels will be build between edge PEs and those in a lot of cases are > > > > located in it's own POP areas. Not to say that there are no customers > > > > who keep most of their PEs on the edges of area 0. > > > > > > > > Rgs, > > > > R. > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 00:56:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09767 for ; Wed, 12 Nov 2003 00:56:50 -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.00C42121@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 0:57:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60239413 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 00:56:59 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 00:56:59 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2003 22:03:40 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAC5uvmU000329 for ; Tue, 11 Nov 2003 21:56:57 -0800 (PST) Received: from cisco.com (rtp-vpn1-30.cisco.com [10.82.224.30]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOD29294; Tue, 11 Nov 2003 21:56:56 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFFBEC.7090409@cisco.com> <20031111211412.Y12111@sapphire.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FB1CBA8.2050608@cisco.com> Date: Tue, 11 Nov 2003 21:56:56 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rahul, Rahul Aggarwal wrote: > Hi Sandy, > > On Mon, 10 Nov 2003, Sandy Eng wrote: > > >>Rahul, >> >>Rahul Aggarwal wrote: >> >>>Following up on this thread, I have the following concerns with this >>>document: >>> >>>1. Tunnels are used both intra and inter domains. Thus tunnel >>>capabilities have to be propagated across domains as well. Hence IGP is >>>imho not appropriate for this application. >>> >>>2. Tunnel capabilities are not used by core routeres. >> >>As we are announcing specific router capabilities, it therefore infers >>that only certain routers in the network are capable of some specific >>capabilities. If all routers in a network have the same capability, >>there is then no need for specific announcement. >> > > > The tunnel encapsulations are needed by the PE routers and are advertised > by the PE routers. Different PE routers can advertise different tunnel > capabailities. However P routers do not require this information. When a capability is announced, one does not expect all routers in a network to react to such capability. One example is draft-vasseur-mpls-ospf-te-cap-00. Do we then require that the RI LSA carries capability information only if all routers in a network need it? If so, I don't see this requirement mandated in draft-lindem-ospf-cap-01. I agree we should not simply stuff any type of information in OSPF. But this should be looked at from application to application. Most of the times, a router announcing as a tunnel endpoint does not change its status. Tunnel application can be mostly viewed as a single shot. Furthermore, there are enterprise networks that are only running IGP (OSPF in this case), which wish to establish tunnels to divert special class of traffic. In such cases, OSPF needs to provision this dynamic discovery. In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes, OSPF can deliver the tunnel endpoint information much faster than BGP, enabling faster traffic reachibility. Thanks, Sandy > > rahul > > >>Thanks, >>Sandy >> >> >> >> >>>3. There are existing documents that specify the use of BGP for this: >>>draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt >>>draft-nalawade-kapoor-tunnel-safi-01.txt >>> >>>Hence imho OSPF WG should not take on this work. >>> >>>Thanks, >>>rahul >>> >>>On Tue, 28 Oct 2003, Robert Raszuk wrote: >>> >>> >>> >>>>Acee, >>>> >>>> >>>> >>>>> My biggest fear would be that if this draft is accepted it >>>>> would only be the first of a torrent of auto-configuration >>>>> drafts. >>>> >>>>Second one not first ;). Notice this one submitted a while back: >>>>draft-raszuk-ospf-bgp-peer-discovery-00.txt >>>> >>>> >>>>> 1. Should OSPF be used for tunnel auto-configuration? >>>> >>>>I think in general this requires a study on a case by case basis. Most >>>>important factors which should be taken into consideration are: >>>> >>>>*A* How frequently the information advertised changed - is it static >>>>configuration or dynamic in nature which triggers reflooding ? >>>> >>>>*B* Is the application which the uses delivered information limited to >>>>IGP domain or crosses domains ? >>>> >>>>*C* What is the amount of information to be flooded (keeping in mind >>>>that majority of P routers - those in the core - will never use it. >>>> >>>>*D* What are the alternatives available & _deployed_ today to deliver >>>>the same information to it's users >>>> >>>>*E* How often area wide flooding will be sufficient versus domain wide. >>>> >>>>Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the >>>>following: >>>> >>>>Reg A: Info is essentially static except the L2TPv3 cookie rollover >>>>intervals which if implementation permits could be changing periodically >>>> >>>>Reg B: I think that in any application of tunnels we can't limit the >>>>scope of use to one IGP domain. There can be a lot of customers who may >>>>never need to go over a domain (which this draft is targeting though). >>>> >>>>Reg C: Minimal (comparing to TE at least :):). >>>> >>>>Reg D: It is worth noting that there is a few drafts in IDR describing >>>>the ideas for the same information distribution >>>> >>>>Reg E: Looking at the most common OSPF topologies I would say that most >>>>tunnels will be build between edge PEs and those in a lot of cases are >>>>located in it's own POP areas. Not to say that there are no customers >>>>who keep most of their PEs on the edges of area 0. >>>> >>>>Rgs, >>>>R. >>>> >>> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 01:09:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09983 for ; Wed, 12 Nov 2003 01:09: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 <10.00C423C5@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 1:09:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60240718 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 01:09:14 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 01:09:14 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 22:12:58 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAC69AiN010070; Tue, 11 Nov 2003 22:09:11 -0800 (PST) Received: from cisco.com (sjc-vpn3-352.cisco.com [10.21.65.96]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANM28285; Tue, 11 Nov 2003 22:09:09 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFFBEC.7090409@cisco.com> <20031111211412.Y12111@sapphire.juniper.net> <3FB1CBA8.2050608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FB1CE85.5040305@cisco.com> Date: Wed, 12 Nov 2003 07:09:09 +0100 Reply-To: Mailing List Sender: Mailing List From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FB1CBA8.2050608@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Sandy, > In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes, > OSPF can deliver the tunnel endpoint information much faster than BGP, > enabling faster traffic reachibility. I can't agree with this statement. BGP convergence intra domain - note within _single_ domain can be in fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as it should be the case) I could argue that even today with most BGP implementations it will converge faster then OSPF when the number of your P routers is decent. I think we could debate more - and yes this draft itself solves some practical cases with not too big overhead for IGPs - but let's at least keep the facts right. Thx, R. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 01:20:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10191 for ; Wed, 12 Nov 2003 01:20:40 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C42359@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 1:20:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60241253 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 01:20:47 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 01:20:47 -0400 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAC6Kki07064 for ; Tue, 11 Nov 2003 22:20:46 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id hAC6Kkt21861 for ; Tue, 11 Nov 2003 22:20:46 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFF964.C21CB274@cisco.com> <20031111205413.D12111@sapphire.juniper.net> <3FB1C9DD.F4BA562B@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20031111220535.E12111@sapphire.juniper.net> Date: Tue, 11 Nov 2003 22:20:46 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FB1C9DD.F4BA562B@cisco.com> Precedence: list Hi Gargi, > its domain using an IGP and redistribute only the inter-AS information on > the border PEs. This is another flaw with doing this in IGP. A BGP only solution doesn't require redistribution between IGP and BGP. > > Not necessarily. Depends on the application. You are narrowing down the scope > to a particular application - which is why you think PE. I agree that common > scenarios would be PE-to-PE. But that does not mean that there won't be scenarios > that have P routers as endpoints. TE-tunnels is one example. > Please explain how/why tunnel capabilities will be used by TE tunnels. > Also note that this draft is a framework for tunnel endpoint signalling and > how and where it is deployed/used and whether the tunnel endpoints are PEs > or Ps depends on the specific application a Provider or an Enterprise has > in mind. > Can you articulate the applications where this information is needed on the P routers ? > > > learnt through an IGP to resolve the nexthop to BGP prefixes. But in > > > the presence of tunnels, this reachability is not sufficient > > and the > > > reachability via the tunnels has to be propagated as well. > > > > For route resolution, the BGP next-hop needs to be reachable. The BGP > > next-hop will be the tunnel endpoint address. This in turn will be an IGP > > route. Why is this not sufficient ? > > Because the reachability would be through the tunnel. Unless the tunnel The control traffic reachability is through the hop by hop path to the tunnel endpoint. Data traffic takes the tunnel. Thanks, rahul From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 02:05:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15286 for ; Wed, 12 Nov 2003 02:05: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 <13.00C42395@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 2:05:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60243600 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 02:05:27 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 02:05:25 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Nov 2003 23:07:31 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAC75Mw5001647; Tue, 11 Nov 2003 23:05:23 -0800 (PST) Received: from cisco.com (rtp-vpn1-13.cisco.com [10.82.224.13]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANM30618; Tue, 11 Nov 2003 23:05:21 -0800 (PST) X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFF964.C21CB274@cisco.com> <20031111205413.D12111@sapphire.juniper.net> <3FB1C9DD.F4BA562B@cisco.com> <20031111220535.E12111@sapphire.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3FB1DBB0.E5694648@cisco.com> Date: Tue, 11 Nov 2003 23:05:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Gargi Nalawade Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Comments: cc: swkeng@cisco.com, jvasseur@cisco.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rahul, Rahul Aggarwal wrote: > > Hi Gargi, > > > its domain using an IGP and redistribute only the inter-AS information on > > the border PEs. > > This is another flaw with doing this in IGP. A BGP only solution doesn't A BGP-only solution *requires* BGP. That is the only flaw with just doing this via BGP. > require redistribution between IGP and BGP. > > > > > Not necessarily. Depends on the application. You are narrowing down the scope > > to a particular application - which is why you think PE. I agree that common > > scenarios would be PE-to-PE. But that does not mean that there won't be scenarios > > that have P routers as endpoints. TE-tunnels is one example. > > > > Please explain how/why tunnel capabilities will be used by TE tunnels. There are numerous examples out there. Look at draft-vasseur-mpls-ospf-te-cap-00.txt > > > Also note that this draft is a framework for tunnel endpoint signalling and > > how and where it is deployed/used and whether the tunnel endpoints are PEs > > or Ps depends on the specific application a Provider or an Enterprise has > > in mind. > > > > Can you articulate the applications where this information is needed on > the P routers ? I just named one. This is not limited/targeted at P routers though. There could be enterprise routers that do not run BGP that need tunneling mechanisms. Sandy's email mentioned an example for that as well. > > > > learnt through an IGP to resolve the nexthop to BGP prefixes. But in > > > > the presence of tunnels, this reachability is not sufficient > > > and the > > > > reachability via the tunnels has to be propagated as well. > > > > > > For route resolution, the BGP next-hop needs to be reachable. The BGP > > > next-hop will be the tunnel endpoint address. This in turn will be an IGP > > > route. Why is this not sufficient ? > > > > Because the reachability would be through the tunnel. Unless the tunnel > > The control traffic reachability is through the hop by hop path to the > tunnel endpoint. Data traffic takes the tunnel. Data traffic cannot take the tunnel path until - 1) the control-plane IGP route-reachability has converged 2) the Tunnel reachability has converged Today - IGPs can give us 1). What is missing is 2) - which is what this draft proposes to add. Thanks, Gargi From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 02:15:53 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23355 for ; Wed, 12 Nov 2003 02:15: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 <9.00C42376@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 2:16:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60244485 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 02:16:01 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 02:16:01 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAC7Fww5008255 for ; Tue, 11 Nov 2003 23:15:58 -0800 (PST) Received: from cisco.com (rtp-vpn1-13.cisco.com [10.82.224.13]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANM31041; Tue, 11 Nov 2003 23:15:57 -0800 (PST) X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFFBEC.7090409@cisco.com> <20031111211412.Y12111@sapphire.juniper.net> <3FB1CBA8.2050608@cisco.com> <3FB1CE85.5040305@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3FB1DE2C.F38FCBE3@cisco.com> Date: Tue, 11 Nov 2003 23:15:56 -0800 Reply-To: Mailing List Sender: Mailing List From: Gargi Nalawade Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Robert, Robert Raszuk wrote: > > Sandy, > > > In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes, > > OSPF can deliver the tunnel endpoint information much faster than BGP, > > enabling faster traffic reachibility. > > I can't agree with this statement. > > BGP convergence intra domain - note within _single_ domain can be in > fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with > default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as > it should be the case) I could argue that even today with most BGP I dont quite agree with - 'prioritizing... as should be the case'. We have debated this in the past and you know my stance. The stance of multiple providers I have talked to, also seems to be the same. They want a simple, scalable BGP which does not affect/compromise on their core ipv4 routing. So let's not talk about BGP here. Reality is, in most generic implementations today, there is an order of magnitude difference between OSPF and BGP. > implementations it will converge faster then OSPF when the number of > your P routers is decent. Let's forget about the 'if's and 'when's for now. Plus convergence is not the only major driving factor. There is a need for a non-BGP solution expressed by the enterprise and provider space alike. > I think we could debate more - and yes this draft itself solves some > practical cases with not too big overhead for IGPs - but let's at least Ok. So you agree that this draft solves practical cases. Hear Ya! -Gargi From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 08:51:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17441 for ; Wed, 12 Nov 2003 08:51:46 -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.00C42A30@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 8:51:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60283530 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 08:51:53 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 08:51:53 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hACDpqi34538 for ; Wed, 12 Nov 2003 05:51:52 -0800 (PST) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11334.1068645112.1@juniper.net> Message-ID: <200311121351.hACDpqi34538@merlot.juniper.net> Date: Wed, 12 Nov 2003 05:51:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Folks, The L2TPv3 part of draft-eng-nalawade-ospf-tunnel-cap-00.txt essentially turns OSPF into an alternative signaling protocol for L2TPv3. Before accepting the draft as a WG document there has to be a clear explanation of why there is a need to create yet another signaling protocol for L2TPv3, and why L2TPv3 signaling is not sufficient. Yakov. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 09:05:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17986 for ; Wed, 12 Nov 2003 09:05:25 -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.00C42AE7@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 9:05:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60283967 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 09:05:31 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 09:05:31 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hACE49i35241; Wed, 12 Nov 2003 06:04:09 -0800 (PST) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14325.1068645849.1@juniper.net> Message-ID: <200311121404.hACE49i35241@merlot.juniper.net> Date: Wed, 12 Nov 2003 06:04:09 -0800 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Comments: To: Gargi Nalawade To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Tue, 11 Nov 2003 23:15:56 PST." <3FB1DE2C.F38FCBE3@cisco.com> Precedence: list Gargi, > Robert Raszuk wrote: > > > > Sandy, > > > > > In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes, > > > OSPF can deliver the tunnel endpoint information much faster than BGP, > > > enabling faster traffic reachibility. > > > > I can't agree with this statement. > > > > BGP convergence intra domain - note within _single_ domain can be in > > fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with > > default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as > > it should be the case) I could argue that even today with most BGP > > I dont quite agree with - 'prioritizing... as should be the case'. We > have debated this in the past and you know my stance. The stance of > multiple providers I have talked to, also seems to be the same. They > want a simple, scalable BGP which does not affect/compromise on their > core ipv4 routing. So let's not talk about BGP here. Don't they also want a simple scalable IGP which does not affect/compromise on their core ipv4 routing. So, let's talk *here* about why BGP overload is bad, while IGP overload is ok. And wrt "BGP which does not affect/compromise on their core ipv4 routing", isn't it *you* who wrote several internet drafts that describe mechanisms to handle this with BGP ? > Reality is, in most generic implementations today, there is an order of > magnitude difference between OSPF and BGP. Vendors who have this problem should fix the IBGP part of their "generic implementation". Yakov. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 09:16:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18417 for ; Wed, 12 Nov 2003 09:16:44 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C42A89@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 9:16:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60284626 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 09:16:52 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 09:16:52 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Nov 2003 06:19:01 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACEGnw5029653; Wed, 12 Nov 2003 06:16:50 -0800 (PST) Received: from cisco.com (sjc-vpn1-255.cisco.com [10.21.96.255]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANM46816; Wed, 12 Nov 2003 06:16:48 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFFBEC.7090409@cisco.com> <20031111211412.Y12111@sapphire.juniper.net> <3FB1CBA8.2050608@cisco.com> <3FB1CE85.5040305@cisco.com> <3FB1DE2C.F38FCBE3@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FB240D0.70506@cisco.com> Date: Wed, 12 Nov 2003 15:16:48 +0100 Reply-To: Mailing List Sender: Mailing List From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FB1DE2C.F38FCBE3@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Gargi, > core ipv4 routing. So let's not talk about BGP here. > > Reality is, in most generic implementations today, there is an order > of magnitude difference between OSPF and BGP. Of course there is. And that's why we should not only talk about BGP here comparing both solutions as about some massive and huge monster but we do need to realize that Tunnel AFI/SAFI's properties and the number of few NLRIs it needs to carry in comparison with thousands of ipv4 or vpnv4 BGP carries is a very significant factor to keep in mind. Cheers, R. > Gargi Nalawade wrote: > > Robert, > > Robert Raszuk wrote: > >>Sandy, >> >> >>>In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes, >>>OSPF can deliver the tunnel endpoint information much faster than BGP, >>>enabling faster traffic reachibility. >> >>I can't agree with this statement. >> >>BGP convergence intra domain - note within _single_ domain can be in >>fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with >>default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as >>it should be the case) I could argue that even today with most BGP > > > I dont quite agree with - 'prioritizing... as should be the case'. We > have debated this in the past and you know my stance. The stance of > multiple providers I have talked to, also seems to be the same. They > want a simple, scalable BGP which does not affect/compromise on their > core ipv4 routing. So let's not talk about BGP here. > > Reality is, in most generic implementations today, there is an order of > magnitude difference between OSPF and BGP. > > >>implementations it will converge faster then OSPF when the number of >>your P routers is decent. > > > Let's forget about the 'if's and 'when's for now. Plus convergence is > not the only major driving factor. There is a need for a non-BGP solution > expressed by the enterprise and provider space alike. > > >>I think we could debate more - and yes this draft itself solves some >>practical cases with not too big overhead for IGPs - but let's at least > > > Ok. So you agree that this draft solves practical cases. Hear Ya! > > -Gargi > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 09:18:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18489 for ; Wed, 12 Nov 2003 09:18:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C42B27@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 9:19:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60284702 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 09:19:05 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 09:19:05 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hACEHhi36010; Wed, 12 Nov 2003 06:17:43 -0800 (PST) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18170.1068646663.1@juniper.net> Message-ID: <200311121417.hACEHhi36010@merlot.juniper.net> Date: Wed, 12 Nov 2003 06:17:43 -0800 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Comments: To: Robert Raszuk To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Wed, 12 Nov 2003 07:09:09 +0100." <3FB1CE85.5040305@cisco.com> Precedence: list > Sandy, > > > In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes, > > OSPF can deliver the tunnel endpoint information much faster than BGP, > > enabling faster traffic reachibility. > > I can't agree with this statement. > > BGP convergence intra domain - note within _single_ domain can be in > fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with > default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as > it should be the case) I could argue that even today with most BGP > implementations it will converge faster then OSPF when the number of > your P routers is decent. > > I think we could debate more - and yes this draft itself solves some > practical cases with not too big overhead for IGPs - but let's at least Could you please enumerate these cases. Yakov. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 09:33:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18967 for ; Wed, 12 Nov 2003 09:33: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 <13.00C429F3@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 9:33:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60285212 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 09:33:23 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 09:33:22 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Nov 2003 06:40:09 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hACEXKAt019800; Wed, 12 Nov 2003 06:33:20 -0800 (PST) Received: from cisco.com (sjc-vpn1-255.cisco.com [10.21.96.255]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANM47576; Wed, 12 Nov 2003 06:33:18 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200311121417.hACEHhi36010@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FB244AE.7000209@cisco.com> Date: Wed, 12 Nov 2003 15:33:18 +0100 Reply-To: Mailing List Sender: Mailing List From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Comments: To: Yakov Rekhter To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200311121417.hACEHhi36010@merlot.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Yakov, Practical cases I have in mind is the pragmatic approach to reuse existing and deployed machinery for flooding information versus designing new one from scratch. That applies to BGP, IGPs, LDP, PIM etc .... I essentially see nothing wrong with providing some one the ability to use OSPF for distributing session IDs and cookies in this example if they wish to do so for some reason. As example for provider who wish to use 2547bis over L2TPv3 for whatever reason and happens to have quite a few confederations with a common IGP it seems simpler to use IGP then a sequence of IBGP/EBGP cycles to get the information distributed. So to make myself clear I would like to see if there is an agreement in general for "protocol reuse". I also think that at some time it may turn better to just define a user configurable container (ala community field) in IGPs where users could put their data and flood without the need to go via new code / new draft each time a need to flood something arises. Cheers, R. > Yakov Rekhter wrote: > >>Sandy, >> >> >>>In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes, >>>OSPF can deliver the tunnel endpoint information much faster than BGP, >>>enabling faster traffic reachibility. >> >>I can't agree with this statement. >> >>BGP convergence intra domain - note within _single_ domain can be in >>fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with >>default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as >>it should be the case) I could argue that even today with most BGP >>implementations it will converge faster then OSPF when the number of >>your P routers is decent. >> >>I think we could debate more - and yes this draft itself solves some >>practical cases with not too big overhead for IGPs - but let's at least > > > Could you please enumerate these cases. > > Yakov. > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 10:27:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21998 for ; Wed, 12 Nov 2003 10:27: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 <20.00C42AA9@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 10:27:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60287787 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 10:27:23 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 10:27:22 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACFRL627864 for ; Wed, 12 Nov 2003 17:27:21 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Nov 2003 17:27:21 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 07:27:17 -0800 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.0.6487.1 Thread-Topic: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 Thread-Index: AcOo2NU2mQclssrNSfabeuLNKpoQZgAV5YIA X-OriginalArrivalTime: 12 Nov 2003 15:27:18.0163 (UTC) FILETIME=[75386E30:01C3A931] Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABDF2@daebe009.americas.nokia.com> Date: Wed, 12 Nov 2003 09:27:17 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > I believe it is configured dead interval (which can be as small as 2 > seconds using base OSPF or 1 second using some tricks). Those are the theoritical limits for the dead interval. What are the practical values ? Default value of the dead interval is 30 seconds in our implementation. Anyway, it seems like a good idea to atleast put this into the draft=20 as a suggested mechanism so that people can do it if they want. I=20 will try to put this into the draft. Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 10:35:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22404 for ; Wed, 12 Nov 2003 10:35: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 <3.00C42C55@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 10:35:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60288185 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 10:35:20 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 10:35:20 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BCF9F2935B1 for ; Wed, 12 Nov 2003 07:35:19 -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 09507-02 for ; Wed, 12 Nov 2003 07:35:19 -0800 (PST) Received: from redback.com (pptp-6-165.redback.com [155.53.6.165]) by prattle.redback.com (Postfix) with ESMTP id A053E2935AE for ; Wed, 12 Nov 2003 07:35:17 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA42ABDF2@daebe009.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FB2532A.9030206@redback.com> Date: Wed, 12 Nov 2003 10:35:06 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABDF2@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh.Gupta@NOKIA.COM wrote: >>I believe it is configured dead interval (which can be as small as 2 >>seconds using base OSPF or 1 second using some tricks). >> >> > >Those are the theoritical limits for the dead interval. What are the >practical values ? Default value of the dead interval is 30 seconds >in our implementation. > My experience is that most people do leave the defaults (10/40) but some definitely set hello//dead intervals lower (although not at the OSPF spec minimum). However, I think most people would tell you they want lower dead intervals and faster convergence. > >Anyway, it seems like a good idea to atleast put this into the draft >as a suggested mechanism so that people can do it if they want. I >will try to put this into the draft. > Great. Thanks, Acee > >Regards >Mukesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 12:46:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29445 for ; Wed, 12 Nov 2003 12:46: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.00C42D84@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 12:46:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60299950 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 12:46:40 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 12:46:39 -0400 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hACHkaxg001307 for ; Wed, 12 Nov 2003 12:46:36 -0500 (EST) Received: from cisco.com (sucia.cisco.com [64.101.210.69]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06762; Wed, 12 Nov 2003 11:46:35 -0600 (CST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA42ABDF1@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FB271FB.1050006@cisco.com> Date: Wed, 12 Nov 2003 11:46:35 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABDF1@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh, You are correct that successfully rekeying all the routers on a link within the router dead interval will preserve the adjacencies. So, I guess I overstated the problem by implying that the draft provides *no* way to do this. However, from an operational perspective, I am uncomfortable with a scheme that puts this sort of real-time constraint on the rekeying process. Since we don't define a key distribution/rekeying protocol, rekeying will be done by "out of band" configuration changes, either manually or via some vendor or user developed automated process. Should these not succeed within the dead interval, the adjacency will be lost. Further, the loss of the adjacency may impair management access to one or more of the routers on that link, making a second try more difficult. Also, as Acee has pointed out, the trend among some users is to shorter hello/dead intervals which will make the time constraint that much harder to meet. So, what I am suggesting is that we specify an *additional* rekeying mechanism that works no matter how long it takes. Regards, - Paul Mukesh.Gupta@NOKIA.COM wrote: > Paul, > > I am happy to receive some comments on the draft :) > > I am just wondering about why you think that re-keying will > always break the adjacency ? > > As the whole authentication process is transparent to OSPF, > the only thing that OSPF will see is some missing packets > (hello packets in a stable situation). If the keys are changed > within say 1 minute on all the routers that are on a common > link (how many ospf routers are gonna be there on a common > link ??), the adjacency won't break. Right ? > > Moreover, if a customer wants to change the keys periodically, > he/she might not choose to do it manaully everytime. And if > they do it with some automated way, 1 minute should be more > than enough to change keys on all the routers. > > So why do you think that it will break the adjacency ?? > > Regards > Mukesh > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext >>Paul Wells >>Sent: Tuesday, November 11, 2003 1:20 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 >> >> >>A concern I have with the current version of >>draft-ietf-ospf-ospfv3-auth is >>that it does not specify a method for rekeying an >>authenticated OSPFv3 link >>without breaking the adjacency. In practice, I think such a >>mechanism will >>be needed for the following reasons: >> >>1. The security provided by a static key decreases with time. The >>experience of 802.11 static WEP keys is one example of this. >> >>2. Our customers aren't going to like a solution that >>requires even brief >>outages for periodic rekeying. >> >>Non-disruptive re-keying of a link should be possible by >>establishing an >>additional input SA with the new key. Once all the routers >>on a link have >>done this, the transmit SAs can be moved over. Finally, once all the >>routers have moved to the new key, the old input SAs can be >>removed. The >>trick will be in reliably controlling and synchronizing this sequence. >> >>If this is a problem that we're going to solve, I'd suggest >>that putting it >>into the draft, at least as a "SHOULD", will make it more likely that >>implementations will interoperate. >> >>Thanks. >> >>- Paul Wells >> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 14:50:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04061 for ; Wed, 12 Nov 2003 14:50: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 <0.00C43264@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 14:50:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60310536 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 14:50:39 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 14:50:39 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-64.cisco.com [171.69.101.64]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hACJock27559 for ; Wed, 12 Nov 2003 11:50:38 -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: <000001c3a956$3ee7dc10$406545ab@amer.cisco.com> Date: Wed, 12 Nov 2003 11:50:38 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <19899595280.20031110164510@psg.com> Precedence: list Content-Transfer-Encoding: 7bit Alex, -> -> -> ->Here's the question I asked at the mic today: -> ->2328 limits the configuration of the VLs so that they can ->only transit through non-backbone areas and always belong to ->the backbone. Among other things this prevents "recursive" ->VLs, i.e., VLs relying on other VLs. -> ->The draft relaxes this and suggests that the TA can belong to ->any area and can transit any area. This opens up a ->possibility for TA1 that belongs to area A1 to transit area ->A2 that has TA2. This means that it could be possible for ->packets to be encapsulated more than once. It seems it could ->also be possible to have recursive TA resolution, e.g. in the ->case above, TA2 transiting area A1. Yes, if TA1 has to transit over area 2 to go from ABR1 to ABR2 and its shortest path goes over another TA ( that is another TA belonging to area 2 exist ) then the packet could be encapsulated / decapsulated one more time in the portion that TA2 traverse if they are multi-hop but note that in any case the packet will be delivered to te remote ABR and there should not be any problem. -> ->Seems that this needs to be given more thought. Could you give an example of a case that could introduce a problem Thanks Sina -> ->-- ->Alex -> ->P.S. Padma also pointed out the possibility for excessive SPF -> calculation, but I'll leave it to her to describe the concern -> she has -> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 14:54:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04163 for ; Wed, 12 Nov 2003 14:54: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 <3.00C431AC@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 14:54:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60310948 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 14:54:21 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 14:54:21 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hACJsKi63628 for ; Wed, 12 Nov 2003 11:54:20 -0800 (PST) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16065.1068666860.1@juniper.net> Message-ID: <200311121954.hACJsKi63628@merlot.juniper.net> Date: Wed, 12 Nov 2003 11:54:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Wed, 12 Nov 2003 15:16:48 +0100." <3FB240D0.70506@cisco.com> Precedence: list Robert, > Gargi, > > > core ipv4 routing. So let's not talk about BGP here. > > > > Reality is, in most generic implementations today, there is an order > > of magnitude difference between OSPF and BGP. > > Of course there is. And that's why we should not only talk about BGP > here comparing both solutions as about some massive and huge monster but > we do need to realize that Tunnel AFI/SAFI's properties and the number > of few NLRIs it needs to carry in comparison with thousands of ipv4 or > vpnv4 BGP carries is a very significant factor to keep in mind. And moreover, we need to keep in mind that there is no need to carry all of them over the same BGP session. Yakov. > > Cheers, > R. > > > > Gargi Nalawade wrote: > > > > Robert, > > > > Robert Raszuk wrote: > > > >>Sandy, > >> > >> > >>>In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes, > >>>OSPF can deliver the tunnel endpoint information much faster than BGP, > >>>enabling faster traffic reachibility. > >> > >>I can't agree with this statement. > >> > >>BGP convergence intra domain - note within _single_ domain can be in > >>fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with > >>default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as > >>it should be the case) I could argue that even today with most BGP > > > > > > I dont quite agree with - 'prioritizing... as should be the case'. We > > have debated this in the past and you know my stance. The stance of > > multiple providers I have talked to, also seems to be the same. They > > want a simple, scalable BGP which does not affect/compromise on their > > core ipv4 routing. So let's not talk about BGP here. > > > > Reality is, in most generic implementations today, there is an order of > > magnitude difference between OSPF and BGP. > > > > > >>implementations it will converge faster then OSPF when the number of > >>your P routers is decent. > > > > > > Let's forget about the 'if's and 'when's for now. Plus convergence is > > not the only major driving factor. There is a need for a non-BGP solution > > expressed by the enterprise and provider space alike. > > > > > >>I think we could debate more - and yes this draft itself solves some > >>practical cases with not too big overhead for IGPs - but let's at least > > > > > > Ok. So you agree that this draft solves practical cases. Hear Ya! > > > > -Gargi > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 15:06:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05171 for ; Wed, 12 Nov 2003 15:06:40 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C4306D@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 15:06:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60312031 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 15:06:47 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 15:06:47 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACK6j621199 for ; Wed, 12 Nov 2003 22:06:45 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Nov 2003 22:06:45 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 12:06:31 -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: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 Thread-Index: AcOpRPraP2qtmiWCR+2n1yNfFc7AfgAEop9w X-OriginalArrivalTime: 12 Nov 2003 20:06:31.0632 (UTC) FILETIME=[7710ED00:01C3A958] Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABDF7@daebe009.americas.nokia.com> Date: Wed, 12 Nov 2003 14:06:31 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Paul, I understand you point and agree with you that we should have a=20 mechanism that works without depending on these real-time=20 restrictions. We will try to come up with something and will post it to the list for review soon. If you have given it a thought and it is easier for you to come up with the text for the draft, we would be more than happy to=20 review it and add it to the draft. I heard that Cisco has implemented the draft. I would like to hear more about the implementation experience and would like to explore the possibility of testing our implementation with yours. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Paul Wells > Sent: Wednesday, November 12, 2003 11:47 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 >=20 >=20 > Mukesh, >=20 > You are correct that successfully rekeying all the routers on a link > within the router dead interval will preserve the adjacencies. So, I > guess I overstated the problem by implying that the draft=20 > provides *no* > way to do this. >=20 > However, from an operational perspective, I am uncomfortable with a > scheme that puts this sort of real-time constraint on the rekeying > process. >=20 > Since we don't define a key distribution/rekeying protocol, rekeying > will be done by "out of band" configuration changes, either=20 > manually or > via some vendor or user developed automated process. Should these not > succeed within the dead interval, the adjacency will be lost.=20 > Further, > the loss of the adjacency may impair management access to one=20 > or more of > the routers on that link, making a second try more difficult. >=20 > Also, as Acee has pointed out, the trend among some users is=20 > to shorter > hello/dead intervals which will make the time constraint that much > harder to meet. >=20 > So, what I am suggesting is that we specify an *additional* rekeying > mechanism that works no matter how long it takes. >=20 > Regards, >=20 > - Paul >=20 > Mukesh.Gupta@NOKIA.COM wrote: > > Paul, > > > > I am happy to receive some comments on the draft :) > > > > I am just wondering about why you think that re-keying will > > always break the adjacency ? > > > > As the whole authentication process is transparent to OSPF, > > the only thing that OSPF will see is some missing packets > > (hello packets in a stable situation). If the keys are changed > > within say 1 minute on all the routers that are on a common > > link (how many ospf routers are gonna be there on a common > > link ??), the adjacency won't break. Right ? > > > > Moreover, if a customer wants to change the keys periodically, > > he/she might not choose to do it manaully everytime. And if > > they do it with some automated way, 1 minute should be more > > than enough to change keys on all the routers. > > > > So why do you think that it will break the adjacency ?? > > > > Regards > > Mukesh > > > > > >>-----Original Message----- > >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On=20 > Behalf Of ext > >>Paul Wells > >>Sent: Tuesday, November 11, 2003 1:20 PM > >>To: OSPF@PEACH.EASE.LSOFT.COM > >>Subject: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03 > >> > >> > >>A concern I have with the current version of > >>draft-ietf-ospf-ospfv3-auth is > >>that it does not specify a method for rekeying an > >>authenticated OSPFv3 link > >>without breaking the adjacency. In practice, I think such a > >>mechanism will > >>be needed for the following reasons: > >> > >>1. The security provided by a static key decreases with time. The > >>experience of 802.11 static WEP keys is one example of this. > >> > >>2. Our customers aren't going to like a solution that > >>requires even brief > >>outages for periodic rekeying. > >> > >>Non-disruptive re-keying of a link should be possible by > >>establishing an > >>additional input SA with the new key. Once all the routers > >>on a link have > >>done this, the transmit SAs can be moved over. Finally,=20 > once all the > >>routers have moved to the new key, the old input SAs can be > >>removed. The > >>trick will be in reliably controlling and synchronizing=20 > this sequence. > >> > >>If this is a problem that we're going to solve, I'd suggest > >>that putting it > >>into the draft, at least as a "SHOULD", will make it more=20 > likely that > >>implementations will interoperate. > >> > >>Thanks. > >> > >>- Paul Wells > >> >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 20:44:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21725 for ; Wed, 12 Nov 2003 20:44: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 <6.00C43934@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 20:44:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60343256 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 20:44:41 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 20:44:41 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L2YB9CTJ828X7LGX@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 17:44:38 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: pmurphy MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L2YB9CTK5W8X7LGX@omega7.wr.usgs.gov> Date: Wed, 12 Nov 2003 17:44:38 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Sina, When I last contacted you about this draft I recommended you drop DC and maintain TAs utilizing Hello processing. Short Router Dead intervals might mitigate the anomalous behavior described in the example below. At the time you felt comfortable that excessive LSA Retransmission would cause these adjacencies to drop in a timely manner. Regardless of how your draft maintains the Full state of its TAs, there might still be an unacceptable lag time before the TAs drop after a critical path component fails. During this lag, packet forwarding may incur endless retunneling. Consider this contrived (for simplicity) example: N2 . . B0 . . . Area 1 . . . Area 2 link . . . link . Area 2 . . . . A0..Area 1..Xs..link...C0 . . . . link . . . . Area 1 Area 2 . . . link link . . . D0 where Area 2 has a TA between A0 and C0 across Area 1, and Area 1 has a TA between B0 and D0 across Area 2. A0, B0, C0, and D0 are Area 0 border routers. Xs is a non-routing switching component common to paths in both areas that has just failed. N2 is a network belonging to Area 2. The intent is for the paths A0..Area.1..Xs..link....C0 and B0..Area.2..Xs..link....D0 to maintain the Area 1 TA and Area 2 TA respectively. Unfortunately, following the failure of Xs, the TAs can also be used to maintain each other until one or the other drops. Here is what happens during the lag. Stage 1 A0 needs to forward a packet through B0 to N2 across Area 2. The direct Area 2 path to N2, namely A0-->D0--Xs-->B0-->N2, is broken. However the Area 1 TA (TA1) between B0 and D0 across Area 2 appears good to A0 (until the TA fails and is removed from the LSDB), creating an apparent Area 1 path between A0 and C0, namely A0-->B0--TA1-->D0-->C0. This in turn makes the Area 2 TA (TA2) between A0 and B0 appear good, thus providing A0 with the illusion of an Area 2 path to N2, namely A0--TA2-->C0-->B0-->N2. So A0 encapsulates the Area 2 packet destined for N2 into a GRE packet destined for C0 in Area 1, and forwards this new GRE packet across its Area 1 direct link to B0. Stage 2 B0 receives this latest GRE packet from A0 whose destination is C0 in Area 1 (not N2 in Area 2). Similar logic causes B0 to ensapsulate this GRE packet into another GRE packet destined for D0 in Area 2, and then B0 forwards this new GRE packet across its Area 2 direct link to C0. Stage 3 C0 receives this latest GRE packet from B0 whose destination is D0 in Area 2 (not C0 in Area 1). Similar logic causes C0 to ensapsulate this GRE packet into another GRE packet destined for A0 in Area 2, and then C0 forwards this latest GRE packet across its Area 1 direct link to D0. Stage 4 D0 receives this latest GRE packet from C0 whose destination is A0 in Area 1 (not D0 in Area 2). Similar logic causes D0 to ensapsulate this GRE packet into another GRE packet destined for B0 in Area 1, and D0 then forwards this new GRE packet across its Area 2 direct link to A0. Stage 5 and beyond A0 receives this latest GRE packet from D0 whose destination is B0 in Area 2 (not A0 in Area 1). This last Area 2 GRE packet destined for B0 in Area 2 is just the original Area 2 packet destined for N2, bundled underneath four GRE encapsulations. Stages 1 through 4 repeat continuously until the TAs drop, effectively producing a short (?) packet flood over the perimeter links of Area 1 and Area 2. Thoughts anyone? How about a simpler example. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 21:15:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22696 for ; Wed, 12 Nov 2003 21:15: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 <20.00C4388B@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 21:15:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60345489 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 21:15:27 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 21:15:27 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L2YCCIBD9K8X7LGX@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 18:15:25 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L2YCCIBE7U8X7LGX@omega7.wr.usgs.gov> Date: Wed, 12 Nov 2003 18:15:25 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Sina, This is being resent due to a couple of incorrect Area #s. Sorry. When I last contacted you about this draft I recommended you drop DC and maintain TAs utilizing Hello processing. Short Router Dead intervals might mitigate the anomalous behavior described in the example below. At the time you felt comfortable that excessive LSA Retransmission would cause these adjacencies to drop in a timely manner. Regardless of how your draft maintains the Full state of its TAs, there might still be an unacceptable lag time before the TAs drop after a critical path component fails. During this lag, packet forwarding may incur endless retunneling. Consider this contrived (for simplicity) example: N2 . . B0 . . . Area 1 . . . Area 2 link . . . link . Area 2 . . . . A0..Area 1..Xs..link...C0 . . . . link . . . . Area 1 Area 2 . . . link link . . . D0 where Area 2 has a TA between A0 and C0 across Area 1, and Area 1 has a TA between B0 and D0 across Area 2. A0, B0, C0, and D0 are Area 0 border routers. Xs is a non-routing switching component common to paths in both areas that has just failed. N2 is a network belonging to Area 2. The intent is for the paths A0..Area.1..Xs..link....C0 and B0..Area.2..Xs..link....D0 to maintain the Area 1 TA and Area 2 TA respectively. Unfortunately, following the failure of Xs, the TAs can also be used to maintain each other until one or the other drops. Here is what happens during the lag. Stage 1 A0 needs to forward a packet through B0 to N2 across Area 2. The direct Area 2 path to N2, namely A0-->D0--Xs-->B0-->N2, is broken. However the Area 1 TA (TA1) between B0 and D0 across Area 2 appears good to A0 (until the TA fails and is removed from the LSDB), creating an apparent Area 1 path between A0 and C0, namely A0-->B0--TA1-->D0-->C0. This in turn makes the Area 2 TA (TA2) between A0 and B0 appear good, thus providing A0 with the illusion of an Area 2 path to N2, namely A0--TA2-->C0-->B0-->N2. So A0 encapsulates the Area 2 packet destined for N2 into a GRE packet destined for C0 in Area 1, and forwards this new GRE packet across its Area 1 direct link to B0. Stage 2 B0 receives this latest GRE packet from A0 whose destination is C0 in Area 1 (not N2 in Area 2). Similar logic causes B0 to ensapsulate this GRE packet into another GRE packet destined for D0 in Area 2, and then B0 forwards this new GRE packet across its Area 2 direct link to C0. Stage 3 C0 receives this latest GRE packet from B0 whose destination is D0 in Area 2 (not C0 in Area 1). Similar logic causes C0 to ensapsulate this GRE packet into another GRE packet destined for A0 in Area 1, and then C0 forwards this latest GRE packet across its Area 1 direct link to D0. Stage 4 D0 receives this latest GRE packet from C0 whose destination is A0 in Area 1 (not D0 in Area 2). Similar logic causes D0 to ensapsulate this GRE packet into another GRE packet destined for B0 in Area 2, and D0 then forwards this new GRE packet across its Area 2 direct link to A0. Stage 5 and beyond A0 receives this latest GRE packet from D0 whose destination is B0 in Area 2 (not A0 in Area 1). This last Area 2 GRE packet destined for B0 in Area 2 is just the original Area 2 packet destined for N2, bundled underneath four GRE encapsulations. Stages 1 through 4 repeat continuously until the TAs drop, effectively producing a short (?) packet flood over the perimeter links of Area 1 and Area 2. Thoughts anyone? How about a simpler example. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 12 21:42:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23259 for ; Wed, 12 Nov 2003 21:42:31 -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.00C43A05@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 21:42:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60347870 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 21:42:40 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 21:42:40 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK7RP-000Ls3-5W; Thu, 13 Nov 2003 02:42:39 +0000 X-Priority: 3 (Normal) References: <19899595280.20031110164510@psg.com> <000001c3a956$3ee7dc10$406545ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16821525492.20031112204200@psg.com> Date: Wed, 12 Nov 2003 20:42:00 -0600 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency Comments: To: Sina Mirtorabi To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c3a956$3ee7dc10$406545ab@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Sina, ->>The draft relaxes this and suggests that the TA can belong to ->>any area and can transit any area. This opens up a ->>possibility for TA1 that belongs to area A1 to transit area ->>A2 that has TA2. This means that it could be possible for ->>packets to be encapsulated more than once. It seems it could ->>also be possible to have recursive TA resolution, e.g. in the ->>case above, TA2 transiting area A1. > Yes, if TA1 has to transit over area 2 to go from ABR1 to ABR2 and its > shortest path goes over another TA ( that is another TA belonging to > area 2 exist ) then the packet could be encapsulated / decapsulated one > more time in the portion that TA2 traverse if they are multi-hop but > note that in any case the packet will be delivered to te remote ABR and > there should not be any problem. In general, because VL in any area can use a VL in any other area, it seems there can be multiple (more than 2) encapsulations. This certainly has some TCP path MTU implications that need to be spelled out. ->>Seems that this needs to be given more thought. > Could you give an example of a case that could introduce a problem The most interesting scenario I had in mind was with recursive TAs. Here is a simple example that would be useful to think through: -+---B1---+-- Area0 | | [R1] [R2] | | -+---B2---+-- Area1 Assume that there are two TA1 between R1 and R2: TA1 belonging to Area 0 and transiting Area 1, and TA2 belonging to Area 1 transiting Area 0. The event to consider is when TAs go up and then segments B1 and B2 go down. Since both TAs are used in SPF, it is possible they will use each other for resolution during SPF. It's a little hard for me to write down a full analysis of this scenario during the IETF week :) I'd appreciate if you looked at this, and I'll try to do so on my flight back on Friday to see if it really is a problem. Cheers. Alex From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 13 00:13:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27979 for ; Thu, 13 Nov 2003 00:13: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 <12.00C43F26@cherry.ease.lsoft.com>; Thu, 13 Nov 2003 0:12:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60364497 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 Nov 2003 00:12:02 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 Nov 2003 00:12:02 -0400 Received: from smirtoraw2k03 (sjc-vpn2-651.cisco.com [10.21.114.139]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAD5Bxk27100 for ; Wed, 12 Nov 2003 21:12:00 -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: <000001c3a9a4$ab8e3460$f2ce7243@amer.cisco.com> Date: Wed, 12 Nov 2003 21:11:59 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01L2YB9CTK5W8X7LGX@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat, 1) The draft specify to send Hello over the TA and one could configure it as DC if required 2) In your analysis, you did not mention what is the shortest path of each TA, if they are the direct links then you would follow that next hop and not through adjacent node which will make the packet to be dropped since the switch is down 3) Assuming the TA's path goes over each other and later the switch goes down, what you described could happen during a transition time ( the time TA will be brought down ) and not a problem with the proposal. As an analogy when a link goes down and during a transition SPF period in the network we can have loop however this does not mean that there is a problem in SPF algorithm. Thanks Sina -> ->Sina, -> ->When I last contacted you about this draft I recommended you ->drop DC and maintain TAs utilizing Hello processing. Short ->Router Dead intervals might mitigate the anomalous behavior ->described in the example below. At the time you felt ->comfortable that excessive LSA Retransmission would cause ->these adjacencies to drop in a timely manner. Regardless of ->how your draft maintains the Full state of its TAs, there ->might still be an unacceptable lag time before the TAs drop ->after a critical path component fails. During this lag, ->packet forwarding may incur endless retunneling. -> ->Consider this contrived (for simplicity) example: -> -> N2 -> . -> . -> B0 -> . . . -> Area 1 . . . Area 2 -> link . . . link -> . Area 2 . -> . . . -> A0..Area 1..Xs..link...C0 -> . . . -> . link . -> . . . Area 1 -> Area 2 . . . link -> link . . . -> D0 -> ->where Area 2 has a TA between A0 and C0 across Area 1, and ->Area 1 has a TA between B0 and D0 across Area 2. A0, B0, C0, ->and D0 are Area 0 border routers. Xs is a non-routing ->switching component common to paths in both areas that has ->just failed. N2 is a network belonging to Area 2. The intent ->is for the paths -> -> A0..Area.1..Xs..link....C0 ->and -> B0..Area.2..Xs..link....D0 -> ->to maintain the Area 1 TA and Area 2 TA respectively. ->Unfortunately, following the failure of Xs, the TAs can also ->be used to maintain each other until one or the other drops. ->Here is what happens during the lag. -> ->Stage 1 -> ->A0 needs to forward a packet through B0 to N2 across Area 2. ->The direct Area 2 path to N2, namely A0-->D0--Xs-->B0-->N2, ->is broken. However the Area 1 TA (TA1) between B0 and D0 ->across Area 2 appears good to A0 (until the TA fails and is ->removed from the LSDB), creating an apparent Area 1 path ->between A0 and C0, namely A0-->B0--TA1-->D0-->C0. This in ->turn makes the Area 2 TA (TA2) between A0 and B0 appear good, ->thus providing A0 with the illusion of an Area 2 path to N2, namely ->A0--TA2-->C0-->B0-->N2. -> ->So A0 encapsulates the Area 2 packet destined for N2 into a ->GRE packet destined for C0 in Area 1, and forwards this new ->GRE packet across its Area 1 direct link to B0. -> ->Stage 2 -> ->B0 receives this latest GRE packet from A0 whose destination ->is C0 in Area 1 (not N2 in Area 2). Similar logic causes B0 ->to ensapsulate this GRE packet into another GRE packet ->destined for D0 in Area 2, and then B0 forwards this new GRE ->packet across its Area 2 direct link to C0. -> ->Stage 3 -> ->C0 receives this latest GRE packet from B0 whose destination ->is D0 in Area 2 (not C0 in Area 1). Similar logic causes C0 ->to ensapsulate this GRE packet into another GRE packet ->destined for A0 in Area 2, and then C0 forwards this latest ->GRE packet across its Area 1 direct link to D0. -> ->Stage 4 -> ->D0 receives this latest GRE packet from C0 whose destination ->is A0 in Area 1 (not D0 in Area 2). Similar logic causes D0 ->to ensapsulate this GRE packet into another GRE packet ->destined for B0 in Area 1, and D0 then forwards this new GRE ->packet across its Area 2 direct link to A0. -> ->Stage 5 and beyond -> ->A0 receives this latest GRE packet from D0 whose destination ->is B0 in Area 2 (not A0 in Area 1). This last Area 2 GRE ->packet destined for B0 in Area 2 is just the original Area 2 ->packet destined for N2, bundled underneath four GRE ->encapsulations. Stages 1 through 4 repeat continuously until ->the TAs drop, effectively producing a short (?) packet flood ->over the perimeter links of Area 1 and Area 2. -> ->Thoughts anyone? How about a simpler example. -> ->Pat -> From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 13 00:34:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28875 for ; Thu, 13 Nov 2003 00:34: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 <20.00C43EBA@cherry.ease.lsoft.com>; Thu, 13 Nov 2003 0:34:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60368994 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 Nov 2003 00:34:20 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 Nov 2003 00:34:20 -0400 Received: from smirtoraw2k03 (sjc-vpn2-651.cisco.com [10.21.114.139]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAD5YJk21322; Wed, 12 Nov 2003 21:34:19 -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: <000001c3a9a7$c946d180$f2ce7243@amer.cisco.com> Date: Wed, 12 Nov 2003 21:34:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency Comments: To: Alex Zinin To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <16821525492.20031112204200@psg.com> Precedence: list Content-Transfer-Encoding: 7bit Alex, -> ->Sina, -> ->->>The draft relaxes this and suggests that the TA can belong to any ->->>area and can transit any area. This opens up a possibility for TA1 ->->>that belongs to area A1 to transit area A2 that has TA2. ->This means ->->>that it could be possible for packets to be encapsulated more than ->->>once. It seems it could also be possible to have recursive TA ->->>resolution, e.g. in the case above, TA2 transiting area A1. -> ->> Yes, if TA1 has to transit over area 2 to go from ABR1 to ->ABR2 and its ->> shortest path goes over another TA ( that is another TA ->belonging to ->> area 2 exist ) then the packet could be encapsulated / decapsulated ->> one more time in the portion that TA2 traverse if they are ->multi-hop ->> but note that in any case the packet will be delivered to te remote ->> ABR and there should not be any problem. -> ->In general, because VL in any area can use a VL in any other ->area, it seems there can be multiple (more than 2) ->encapsulations. I guess you mean TA ;-) The usage of TA is pretty simple, i.e. use backbone area as a transit area for non-backbone areas. this is true for 1) using high speed link of the backbone 2) in Hub and spoke topology have multiple TA over backbone link 3) on demand partition repair for non-backbone area that are summarized I personally fail to see why one would configure mutual TA, i.e. TA1 going through area X and belonging to Y and TA2 going through area Y and belonging to X but even in those case there won't be a problem ->This certainly has some TCP path MTU ->implications that need to be spelled out. Sure, we will add this in the next version -> ->->>Seems that this needs to be given more thought. -> ->> Could you give an example of a case that could introduce a problem -> ->The most interesting scenario I had in mind was with ->recursive TAs. Here is a simple example that would be useful ->to think through: -> -> -+---B1---+-- Area0 -> | | -> [R1] [R2] -> | | -> -+---B2---+-- Area1 -> ->Assume that there are two TA1 between R1 and R2: TA1 ->belonging to Area 0 and transiting Area 1, and TA2 belonging ->to Area 1 transiting Area 0. The event to consider is when ->TAs go up and then segments B1 and B2 go down. Since both TAs ->are used in SPF, it is possible they will use each other for ->resolution during SPF. -> ->It's a little hard for me to write down a full analysis of ->this scenario during the IETF week :) I know, it is pretty good that you responded I was expecting your e-mail not before next week ;-) ->I'd appreciate if you ->looked at this, and I'll try to do so on my flight back on ->Friday to see if it really is a problem. Ok A) I bring up TA1 which transit through area 0 and belong to area 1, initially its SPT is through link B1 B) I bring up TA2 which transit through area 1 and belong to area 0, initially its SPT is through link B2 C) TA1 and TA2 could switch from direct link trough each other D) B1 and B2 goes down E) TA1 and TA2 are backing each other up However the Hello will make sure that the TA will be brought down, therefore we do need to send Hello over TA in those scenarios instead of considering it as DC Thanks Sina -> ->Cheers. ->Alex -> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 10:17:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14931 for ; Fri, 14 Nov 2003 10:17:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C463BC@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 10:18:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60560743 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 10:18:04 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 10:18:03 -0400 Received: from smirtoraw2k03 (sjc-vpn3-800.cisco.com [10.21.67.32]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAEFI2k20812 for ; Fri, 14 Nov 2003 07:18:02 -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: <002401c3aac2$7f216c20$f2ce7243@amer.cisco.com> Date: Fri, 14 Nov 2003 07:18:02 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c3a9a4$ab8e3460$f2ce7243@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Pat One important correction below -> ->Pat, -> ->1) The draft specify to send Hello over the TA and one could ->configure it as DC if required -> ->2) In your analysis, you did not mention what is the shortest ->path of each TA, if they are the direct links then you would ->follow that next hop and not through adjacent node which will ->make the packet to be dropped since the switch is down -> ->3) Assuming the TA's path goes over each other and later the ->switch goes down, what you described could happen during a ->transition time Actually this can NEVER happen. This is because TA shortest path can never go through each other as cost are positive ( one can go over the other but not over each other ) therefore in your example after the first GRE encapsulation you would drop the packet since the switch is down. Thanks Sina PS: Alex, this is also true for your example, two TA's SPT can not go over each other therefore they can never backup each other ( the time TA will be brought down ) and not ->a problem with the proposal. As an analogy when a link goes ->down and during a transition SPF period in the network we can ->have loop however this does not mean that there is a problem ->in SPF algorithm. -> ->Thanks ->Sina -> ->-> ->->Sina, ->-> ->->When I last contacted you about this draft I recommended ->you drop DC ->->and maintain TAs utilizing Hello processing. Short Router Dead ->->intervals might mitigate the anomalous behavior described in the ->->example below. At the time you felt comfortable that excessive LSA ->->Retransmission would cause these adjacencies to drop in a timely ->->manner. Regardless of how your draft maintains the Full ->state of its ->->TAs, there might still be an unacceptable lag time before ->the TAs drop ->->after a critical path component fails. During this lag, ->->packet forwarding may incur endless retunneling. ->-> ->->Consider this contrived (for simplicity) example: ->-> ->-> N2 ->-> . ->-> . ->-> B0 ->-> . . . ->-> Area 1 . . . Area 2 ->-> link . . . link ->-> . Area 2 . ->-> . . . ->-> A0..Area 1..Xs..link...C0 ->-> . . . ->-> . link . ->-> . . . Area 1 ->-> Area 2 . . . link ->-> link . . . ->-> D0 ->-> ->->where Area 2 has a TA between A0 and C0 across Area 1, and ->Area 1 has ->->a TA between B0 and D0 across Area 2. A0, B0, C0, and D0 are Area 0 ->->border routers. Xs is a non-routing switching component common to ->->paths in both areas that has just failed. N2 is a network ->belonging to ->->Area 2. The intent is for the paths ->-> ->-> A0..Area.1..Xs..link....C0 ->->and ->-> B0..Area.2..Xs..link....D0 ->-> ->->to maintain the Area 1 TA and Area 2 TA respectively. ->Unfortunately, ->->following the failure of Xs, the TAs can also be used to ->maintain each ->->other until one or the other drops. Here is what happens during the ->->lag. ->-> ->->Stage 1 ->-> ->->A0 needs to forward a packet through B0 to N2 across Area 2. The ->->direct Area 2 path to N2, namely A0-->D0--Xs-->B0-->N2, is broken. ->->However the Area 1 TA (TA1) between B0 and D0 across Area 2 appears ->->good to A0 (until the TA fails and is removed from the ->LSDB), creating ->->an apparent Area 1 path between A0 and C0, namely ->->A0-->B0--TA1-->D0-->C0. This in turn makes the Area 2 TA ->(TA2) between ->->A0 and B0 appear good, thus providing A0 with the illusion ->of an Area ->->2 path to N2, namely ->->A0--TA2-->C0-->B0-->N2. ->-> ->->So A0 encapsulates the Area 2 packet destined for N2 into a ->GRE packet ->->destined for C0 in Area 1, and forwards this new GRE packet ->across its ->->Area 1 direct link to B0. ->-> ->->Stage 2 ->-> ->->B0 receives this latest GRE packet from A0 whose ->destination is C0 in ->->Area 1 (not N2 in Area 2). Similar logic causes B0 to ->ensapsulate this ->->GRE packet into another GRE packet destined for D0 in Area ->2, and then ->->B0 forwards this new GRE packet across its Area 2 direct link to C0. ->-> ->->Stage 3 ->-> ->->C0 receives this latest GRE packet from B0 whose ->destination is D0 in ->->Area 2 (not C0 in Area 1). Similar logic causes C0 to ->ensapsulate this ->->GRE packet into another GRE packet destined for A0 in Area ->2, and then ->->C0 forwards this latest GRE packet across its Area 1 direct link to ->->D0. ->-> ->->Stage 4 ->-> ->->D0 receives this latest GRE packet from C0 whose ->destination is A0 in ->->Area 1 (not D0 in Area 2). Similar logic causes D0 to ->ensapsulate this ->->GRE packet into another GRE packet destined for B0 in Area ->1, and D0 ->->then forwards this new GRE packet across its Area 2 direct ->link to A0. ->-> ->->Stage 5 and beyond ->-> ->->A0 receives this latest GRE packet from D0 whose ->destination is B0 in ->->Area 2 (not A0 in Area 1). This last Area 2 GRE packet ->destined for B0 ->->in Area 2 is just the original Area 2 packet destined for ->N2, bundled ->->underneath four GRE encapsulations. Stages 1 through 4 repeat ->->continuously until the TAs drop, effectively producing a short (?) ->->packet flood over the perimeter links of Area 1 and Area 2. ->-> ->->Thoughts anyone? How about a simpler example. ->-> ->->Pat ->-> -> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 10:40:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16413 for ; Fri, 14 Nov 2003 10:40: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 <14.00C46434@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 10:41:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60562441 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 10:40:57 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 10:40:57 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0FA95179EAC for ; Fri, 14 Nov 2003 07:40:57 -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 00191-07 for ; Fri, 14 Nov 2003 07:40:56 -0800 (PST) Received: from redback.com (pptp-6-156.redback.com [155.53.6.156]) by prattle.redback.com (Postfix) with ESMTP id 77884179EAA for ; Fri, 14 Nov 2003 07:40:56 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <19899595280.20031110164510@psg.com> <000001c3a956$3ee7dc10$406545ab@amer.cisco.com> <16821525492.20031112204200@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FB4F77D.2040405@redback.com> Date: Fri, 14 Nov 2003 10:40:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <16821525492.20031112204200@psg.com> Precedence: list Content-Transfer-Encoding: 7bit This is in response to Sina's most recent post on this subject. I wanted to reply to this E-mail to preserve Alex's example. Hi Sina, I must be missing something since I don't understand why it wouldn't be a problem if you simultaneously lost physical connectivity through areas 1 and 2. Without some extra next-hop checking, it seems that area 0 could use the TA through area 1 and vice versa. Granted, packets would not be delivered and the adjacency would go down in RouterDeadInterval seconds (which in turn would result in the TAs being brought down). I think it would simplify implementation/debugging to say that a TA should not be considered up unless the best path through its transit area is not over a another TA. Alex Zinin wrote: >Sina, > >->>The draft relaxes this and suggests that the TA can belong to >->>any area and can transit any area. This opens up a >->>possibility for TA1 that belongs to area A1 to transit area >->>A2 that has TA2. This means that it could be possible for >->>packets to be encapsulated more than once. It seems it could >->>also be possible to have recursive TA resolution, e.g. in the >->>case above, TA2 transiting area A1. > > > >>Yes, if TA1 has to transit over area 2 to go from ABR1 to ABR2 and its >>shortest path goes over another TA ( that is another TA belonging to >>area 2 exist ) then the packet could be encapsulated / decapsulated one >>more time in the portion that TA2 traverse if they are multi-hop but >>note that in any case the packet will be delivered to te remote ABR and >>there should not be any problem. >> >> > >In general, because VL in any area can use a VL in any other area, it >seems there can be multiple (more than 2) encapsulations. This >certainly has some TCP path MTU implications that need to be spelled >out. > >->>Seems that this needs to be given more thought. > > > >>Could you give an example of a case that could introduce a problem >> >> > >The most interesting scenario I had in mind was with recursive TAs. >Here is a simple example that would be useful to think through: > > -+---B1---+-- Area0 > | | > [R1] [R2] > | | > -+---B2---+-- Area1 > >Assume that there are two TA1 between R1 and R2: TA1 belonging to >Area 0 and transiting Area 1, and TA2 belonging to Area 1 transiting >Area 0. The event to consider is when TAs go up and then segments B1 >and B2 go down. Since both TAs are used in SPF, it is possible they >will use each other for resolution during SPF. > >It's a little hard for me to write down a full analysis of this >scenario during the IETF week :) I'd appreciate if you looked at >this, and I'll try to do so on my flight back on Friday to see if >it really is a problem. > >Cheers. >Alex > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 11:50:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19958 for ; Fri, 14 Nov 2003 11:50: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 <3.00C466FB@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 11:50:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60567461 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 11:50:16 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 11:50:12 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-64.cisco.com [171.69.101.64]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAEGoBk26192 for ; Fri, 14 Nov 2003 08:50:11 -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: <002d01c3aacf$5eac53d0$f2ce7243@amer.cisco.com> Date: Fri, 14 Nov 2003 08:50:11 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FB4F77D.2040405@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, -> ->This is in response to Sina's most recent post on this ->subject. I wanted to reply to this E-mail to preserve Alex's example. Let's take Alex example, TA1 belong to area 1 ------> -+---B1---+-- Area0 | | [R1] [R2] | | -+---B2---+-- Area1 -----> TA0 belong to area 0 -> ->Hi Sina, ->I must be missing something since I don't understand why it ->wouldn't be a problem if you simultaneously lost physical ->connectivity through areas 1 and 2. Without some extra ->next-hop checking, it seems that area 0 could use the TA ->through area 1 and vice versa. Before links goes down TA0 and TA1 cannot goes over each other, say TA1 goes over TA0 1) When links goes down, if you don't notice that the links are down ( switch in the middle ) then nothing happen that is TA0 and TA1 are still not going through each other and after the RouterDeadInterval TA are delared down 2) If you detect that the link is down in that case the interface associated with TA could be brought down and still TA are not going over each other In any case assuming that in 2) we don't bring down the interface associated with TA and since your physical interface is down you use the other TA to announce adjacency But I do not see why this is different than when a link is down and the time to detect it through Hello we still announcing the adjacency over it ? ->Granted, packets would not be ->delivered and the adjacency would go down in ->RouterDeadInterval seconds (which in turn would result in the ->TAs being brought down). Yes the important point is that even in those corner cases you still have Hello to bring down the adjacency. Thanks Sina -> ->I think it would simplify implementation/debugging to say ->that a TA should not be considered up unless the best path ->through its transit area is not over a another TA. -> ->Alex Zinin wrote: -> ->>Sina, ->> ->>->>The draft relaxes this and suggests that the TA can belong to any ->>->>area and can transit any area. This opens up a ->possibility for TA1 ->>->>that belongs to area A1 to transit area A2 that has TA2. ->This means ->>->>that it could be possible for packets to be encapsulated ->more than ->>->>once. It seems it could also be possible to have recursive TA ->>->>resolution, e.g. in the case above, TA2 transiting area A1. ->> ->> ->> ->>>Yes, if TA1 has to transit over area 2 to go from ABR1 to ->ABR2 and its ->>>shortest path goes over another TA ( that is another TA ->belonging to ->>>area 2 exist ) then the packet could be encapsulated / decapsulated ->>>one more time in the portion that TA2 traverse if they are ->multi-hop ->>>but note that in any case the packet will be delivered to te remote ->>>ABR and there should not be any problem. ->>> ->>> ->> ->>In general, because VL in any area can use a VL in any other ->area, it ->>seems there can be multiple (more than 2) encapsulations. This ->>certainly has some TCP path MTU implications that need to be spelled ->>out. ->> ->>->>Seems that this needs to be given more thought. ->> ->> ->> ->>>Could you give an example of a case that could introduce a problem ->>> ->>> ->> ->>The most interesting scenario I had in mind was with recursive TAs. ->>Here is a simple example that would be useful to think through: ->> ->> -+---B1---+-- Area0 ->> | | ->> [R1] [R2] ->> | | ->> -+---B2---+-- Area1 ->> ->>Assume that there are two TA1 between R1 and R2: TA1 ->belonging to Area ->>0 and transiting Area 1, and TA2 belonging to Area 1 ->transiting Area 0. ->>The event to consider is when TAs go up and then segments B1 ->and B2 go ->>down. Since both TAs are used in SPF, it is possible they ->will use each ->>other for resolution during SPF. ->> ->>It's a little hard for me to write down a full analysis of this ->>scenario during the IETF week :) I'd appreciate if you ->looked at this, ->>and I'll try to do so on my flight back on Friday to see if ->it really ->>is a problem. ->> ->>Cheers. ->>Alex ->> ->> ->> -> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 13:01:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22555 for ; Fri, 14 Nov 2003 13:01:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C46848@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 13:02:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60572251 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 13:02:06 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 13:02:06 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L30NOJHM6I8X2BAC@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 10:02:04 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L30NOJHM6K8X2BAC@omega7.wr.usgs.gov> Date: Fri, 14 Nov 2003 10:02:04 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Sina, In your original draft TAs were never tied to a path whose first hop must use a specific interface or link whose status can be monitored. Has that changed? I almost posted a more complicated example with intermediate routers A1 and C1 in Area 1, and B2 and D2 in Area 2. In this case A0, B0, C0, and D0 do not see Xs fail. N2 . . B0 . . . Area 1 . . . Area 2 link . . . link . B2 . . . . A0....A1...Xs....C1...C0 . . . . . . . D2 . Area 1 Area 2 . . . link link . . . D0 Its very hard to build a straightforward non-contrived example of a cloud of routers with a bevy of backup tunnels supporting them. In general there would be multiple hopes. Given that SPF calculations of distinct areas are completely disjoint, I do see these lag times during which packet storms can exist. It would be a difficult scenario to troubleshoot. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 13:18:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23298 for ; Fri, 14 Nov 2003 13:18:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C4682D@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 13:18:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60573314 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 13:18:52 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 13:18:52 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-64.cisco.com [171.69.101.64]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAEIIlk25765 for ; Fri, 14 Nov 2003 10:18:48 -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: <003301c3aadb$bf547990$f2ce7243@amer.cisco.com> Date: Fri, 14 Nov 2003 10:18:48 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01L30NOJHM6K8X2BAC@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat, Let me Mention one more time. In your example with endless encapsulation you *assumed* that TA1 path goes over each other therefore endless encapsulation occur during the failure detection. The fact is that TA path cannot go over each other therefore after the first encapsulation the packet will be dropped. It has nothing to do with detecting the failure If you still think that this is possible please provide metric with the shortest path taken with each TA in your example Thanks Sina -> ->Sina, -> ->In your original draft TAs were never tied to a path whose ->first hop must use a specific interface or link whose status ->can be monitored. Has that changed? I almost posted a more ->complicated example with intermediate routers A1 and C1 in ->Area 1, and B2 and D2 in Area 2. In this case A0, B0, C0, and ->D0 do not see Xs fail. -> -> N2 -> . -> . -> B0 -> . . . -> Area 1 . . . Area 2 -> link . . . link -> . B2 . -> . . . -> A0....A1...Xs....C1...C0 -> . . . -> . . . -> . D2 . Area 1 -> Area 2 . . . link -> link . . . -> D0 -> ->Its very hard to build a straightforward non-contrived ->example of a cloud of routers with a bevy of backup tunnels ->supporting them. In general there would be multiple hopes. ->Given that SPF calculations of distinct areas are completely ->disjoint, I do see these lag times during which packet storms ->can exist. It would be a difficult scenario to troubleshoot. -> ->Pat -> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 13:44:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24089 for ; Fri, 14 Nov 2003 13:44: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 <4.00C468A8@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 13:44:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60575197 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 13:44:32 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 13:44:32 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L30P6460OG8X2BH9@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 10:44:29 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L30P6462KI8X2BH9@omega7.wr.usgs.gov> Date: Fri, 14 Nov 2003 10:44:29 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list >The fact is that TA path cannot go over each other therefore after the >first encapsulation the packet will be dropped. What's confusing me is that I remember anything in your draft that prevents this. Perhaps your new posting will be more illuminating. >It has nothing to do with detecting the failure. >If you still think that this is possible please provide metric with the >shortest path taken with each TA in your example So assume that the Xs failure is detected imediately by the SPF algorithm of each Area, that the TAs have metric 100, the direct links have metric 1, and that the TA RouterDead interval (or LSU failure) keeps the TAs up for 10 seconds after the failure is detected. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 14:24:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25217 for ; Fri, 14 Nov 2003 14:24:59 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C469C8@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 14:25:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60579087 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 14:25:08 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 14:25:08 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-64.cisco.com [171.69.101.64]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAEJP6k02942 for ; Fri, 14 Nov 2003 11:25:07 -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: <003c01c3aae5$03493d30$f2ce7243@amer.cisco.com> Date: Fri, 14 Nov 2003 11:25:06 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01L30P6462KI8X2BH9@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat, ->>The fact is that TA path cannot go over each other therefore ->after the ->>first encapsulation the packet will be dropped. P->What's confusing me is that I remember anything in your draft P->that prevents this. Perhaps your new posting will be more P->illuminating. In a normal scenario, a simple match shows that two TA cannot go over each other - TA1 is going over a physical link with a cost of C1, so TA1 cost is C1 - TA2 is going over a physical link with a cost of C2, so TA2 cost is C2 TA1 can go over TA2 if C1 > C2 [i] ( that is the direct cost is more ) Now once [i] is true TA2 cannot go any more over TA2 because for that we should have C2 > C1 which is against [i] ->>It has nothing to do with detecting the failure. -> ->>If you still think that this is possible please provide ->metric with the ->>shortest path taken with each TA in your example P->So assume that the Xs failure is detected imediately by the P->SPF algorithm of each Area, that the TAs have metric 100, the P->direct links have metric 1, and that the TA RouterDead P->interval (or LSU failure) keeps the TAs up for 10 seconds P->after the failure is detected. In a failure scenario where you detect quickly that your link is down and the only remaining path or shortest path is the other TA, for the duration that the TA is brought down you could use the other TA As I have stated before this is only during a transition time that TA are brought down. I believe if there are real concerns for that we can do what Acee suggested, i.e never use a TA in the SPT of another TA Thanks Sina From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 14:58:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26369 for ; Fri, 14 Nov 2003 14:58:26 -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.00C46A76@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 14:58:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60582258 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 14:58:35 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 14:58:35 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L30RQXBRFW8X2BH9@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 11:58:31 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L30RQXBRFY8X2BH9@omega7.wr.usgs.gov> Date: Fri, 14 Nov 2003 11:58:31 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list >As I have stated before this is only during a transition time that TA >are brought down. In the original posting my only concern was during the transition (lag) time till the TAs drop. There was never any statement that the TAs would use one another during normal operation. I do think this is a concern if you don't want an outage over a specific link adversely effecting other links. Intermittant packet floods caused by flapping links are nasty things. While its difficult to devise a simple example, its not hard to imagine one in real life. >I believe if there are real concerns for that we can >do what Acee suggested, i.e never use a TA in the SPT of another TA How does that help if one TA is in Area 1 and the other TA is in Area 2? Pat From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 17:47:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02618 for ; Fri, 14 Nov 2003 17:47: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 <16.00C46EE7@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 17:47:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60595971 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 17:47:48 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 17:47:48 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-64.cisco.com [171.69.101.64]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAEMlmk25799 for ; Fri, 14 Nov 2003 14:47:48 -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: <004f01c3ab01$53796ed0$f2ce7243@amer.cisco.com> Date: Fri, 14 Nov 2003 14:47:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01L30RQXBRFY8X2BH9@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat, P->In the original posting my only concern was during the transition P->(lag) time till the TAs drop. There was never any statement P->that the TAs would use one another during normal operation. Good, we agree on that one. P->I do think this is a concern if you don't want an outage over a P->specific link adversely effecting other links. This may also be true for a normal link. if links goes down, flooding occur, SPF occur and transient loop exist and traffic data path can overload other links S->>I believe if there are real concerns for that we can S->>do what Acee suggested, i.e never use a TA in the SPT of another TA P->How does that help if one TA is in Area 1 and the other TA is P->in Area 2? I was thinking to Not use a TA in another TA's SPT in order to take care of the recursive TA. So if you have TA1 belonging to area 1 and TA2 belonging to area 2, when doing SPF for area 2 you don't want to use TA2 link ( which belong to area 2) however it may not be easy to distinguish a TA link during SPF since it is a p2p link. We agree that TA cannot goes over each other during normal operation, if transition occur and during RouterDeadInterval ( which can be default to lower values ) and in some corner cases where mutual TA configuration is done you may have encapsulations during RouterDeadInterval of the TA. As I have stated before TA usage and design is pretty simple and consists of the following : * using high speed link of the backbone for transit area * in Hub and spoke topology have multiple TA over backbone link ( path ) * on demand partition repair for non-backbone area that are summarized Therefore I do not see any problem in the current draft. Now if you would still argue and there are real concerns regarding recursive TA ( which may happen during RouterDeadInterval ) from other WG members, I can modify the proposal to avoid the recursive TA. Thanks Sina From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 14 18:11:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04017 for ; Fri, 14 Nov 2003 18:11:00 -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.00C46EAB@cherry.ease.lsoft.com>; Fri, 14 Nov 2003 18:11:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60598099 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 18:11:11 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Nov 2003 18:11:11 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L30YHP8G1S8X2BH9@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Nov 2003 15:11:08 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L30YHP8G1U8X2BH9@omega7.wr.usgs.gov> Date: Fri, 14 Nov 2003 15:11:07 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Sina, >however it may not be easy to distinguish a TA link during SPF since it >is a p2p link. Very true. Keep in mind the example I posted is very contrived for simplicity but represents what I believe is a subtle sink hole that a customer could unknowningly fall into. Placing a tunnel here and there may seem harmless, but once you have more than one in the OSPF domain topology, all bets are off. There is nothing wrong with your applications: >* using high speed link of the backbone for transit area >* in Hub and spoke topology have multiple TA over backbone link ( path ) >* on demand partition repair for non-backbone area that are summarized but customers are nortorious for stretching the limits of feature and its the poor folk on the cisco hot line that have to troubleshoot such subtle anomalies. This feature needs to be carefully deployed. A cautious technical writeup is warranted Its nice to see an OSPF draft that features enterprise applicability. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 17 04:45:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06775 for ; Mon, 17 Nov 2003 04:45:36 -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.00C49F9B@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 4:45:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60827821 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 04:45:27 -0500 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 04:45:27 -0400 Received: from cisco.com (ppsenak--isdn-home2.cisco.com [10.49.2.219]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAH9jP716291 for ; Mon, 17 Nov 2003 10:45:26 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <19899595280.20031110164510@psg.com> <000001c3a956$3ee7dc10$406545ab@amer.cisco.com> <16821525492.20031112204200@psg.com> <3FB4F77D.2040405@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FB898B5.2020907@cisco.com> Date: Mon, 17 Nov 2003 10:45:25 +0100 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, Acee Lindem wrote: > This is in response to Sina's most recent post on this subject. I > wanted to > reply to this E-mail to preserve Alex's example. > > Hi Sina, > I must be missing something since I don't understand why it wouldn't be > a problem > if you simultaneously lost physical connectivity through areas 1 and 2. > Without some > extra next-hop checking, it seems that area 0 could use the TA through > area 1 and > vice versa. Granted, packets would not be delivered and the adjacency > would go > down in RouterDeadInterval seconds (which in turn would result in the > TAs being > brought down). > > I think it would simplify implementation/debugging to say that a TA > should not be > considered up unless the best path through its transit area is not over > a another TA. just wondering how would you distinguish the TA link from any other p2p link during SPF, given that the TA in each area can be configured between different set of routers. thanks, Peter > > > Alex Zinin wrote: > >> Sina, >> >> ->>The draft relaxes this and suggests that the TA can belong to >> ->>any area and can transit any area. This opens up a >> ->>possibility for TA1 that belongs to area A1 to transit area >> ->>A2 that has TA2. This means that it could be possible for >> ->>packets to be encapsulated more than once. It seems it could >> ->>also be possible to have recursive TA resolution, e.g. in the >> ->>case above, TA2 transiting area A1. >> >> >> >>> Yes, if TA1 has to transit over area 2 to go from ABR1 to ABR2 and its >>> shortest path goes over another TA ( that is another TA belonging to >>> area 2 exist ) then the packet could be encapsulated / decapsulated one >>> more time in the portion that TA2 traverse if they are multi-hop but >>> note that in any case the packet will be delivered to te remote ABR and >>> there should not be any problem. >>> >>> >> >> In general, because VL in any area can use a VL in any other area, it >> seems there can be multiple (more than 2) encapsulations. This >> certainly has some TCP path MTU implications that need to be spelled >> out. >> >> ->>Seems that this needs to be given more thought. >> >> >> >>> Could you give an example of a case that could introduce a problem >>> >>> >> >> The most interesting scenario I had in mind was with recursive TAs. >> Here is a simple example that would be useful to think through: >> >> -+---B1---+-- Area0 >> | | >> [R1] [R2] >> | | >> -+---B2---+-- Area1 >> >> Assume that there are two TA1 between R1 and R2: TA1 belonging to >> Area 0 and transiting Area 1, and TA2 belonging to Area 1 transiting >> Area 0. The event to consider is when TAs go up and then segments B1 >> and B2 go down. Since both TAs are used in SPF, it is possible they >> will use each other for resolution during SPF. >> >> It's a little hard for me to write down a full analysis of this >> scenario during the IETF week :) I'd appreciate if you looked at >> this, and I'll try to do so on my flight back on Friday to see if >> it really is a problem. >> >> Cheers. >> Alex >> >> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 17 08:57:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11822 for ; Mon, 17 Nov 2003 08:57:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C4A4B6@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 8:58:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60885576 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 08:58:03 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 08:58:02 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 44D8886DAA7 for ; Mon, 17 Nov 2003 05:58:02 -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 16138-07 for ; Mon, 17 Nov 2003 05:58:01 -0800 (PST) Received: from redback.com (unknown [155.53.6.19]) by prattle.redback.com (Postfix) with ESMTP id 5107486DAA5 for ; Mon, 17 Nov 2003 05:58:01 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <19899595280.20031110164510@psg.com> <000001c3a956$3ee7dc10$406545ab@amer.cisco.com> <16821525492.20031112204200@psg.com> <3FB4F77D.2040405@redback.com> <3FB898B5.2020907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FB8D3E5.5050704@redback.com> Date: Mon, 17 Nov 2003 08:57:57 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FB898B5.2020907@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Peter Psenak wrote: > Hi Acee, > > Acee Lindem wrote: > >> This is in response to Sina's most recent post on this subject. I >> wanted to >> reply to this E-mail to preserve Alex's example. >> >> Hi Sina, >> I must be missing something since I don't understand why it wouldn't be >> a problem >> if you simultaneously lost physical connectivity through areas 1 and 2. >> Without some >> extra next-hop checking, it seems that area 0 could use the TA through >> area 1 and >> vice versa. Granted, packets would not be delivered and the adjacency >> would go >> down in RouterDeadInterval seconds (which in turn would result in the >> TAs being >> brought down). >> >> I think it would simplify implementation/debugging to say that a TA >> should not be >> considered up unless the best path through its transit area is not over >> a another TA. > > > > just wondering how would you distinguish the TA link from any other p2p > link during SPF, given that the TA in each area can be configured > between different set of routers. Hi Peter, I should have been clearer. After you run an SPF for a transit area, you need to check the TAs to determine if they should be brought up/down or stay the same (actually you could be smart about which ones you check). I'm proposing to augment this checking to assure a TA's status is not "up" if the best path through a transit area is not via a different locally configured TA in another transit area. Make sense? I could be missing something since this is all based on mental simulation :^) Thanks, Acee > > > thanks, > Peter > >> >> >> Alex Zinin wrote: >> >>> Sina, >>> >>> ->>The draft relaxes this and suggests that the TA can belong to >>> ->>any area and can transit any area. This opens up a >>> ->>possibility for TA1 that belongs to area A1 to transit area >>> ->>A2 that has TA2. This means that it could be possible for >>> ->>packets to be encapsulated more than once. It seems it could >>> ->>also be possible to have recursive TA resolution, e.g. in the >>> ->>case above, TA2 transiting area A1. >>> >>> >>> >>>> Yes, if TA1 has to transit over area 2 to go from ABR1 to ABR2 and its >>>> shortest path goes over another TA ( that is another TA belonging to >>>> area 2 exist ) then the packet could be encapsulated / decapsulated >>>> one >>>> more time in the portion that TA2 traverse if they are multi-hop but >>>> note that in any case the packet will be delivered to te remote ABR >>>> and >>>> there should not be any problem. >>>> >>>> >>> >>> In general, because VL in any area can use a VL in any other area, it >>> seems there can be multiple (more than 2) encapsulations. This >>> certainly has some TCP path MTU implications that need to be spelled >>> out. >>> >>> ->>Seems that this needs to be given more thought. >>> >>> >>> >>>> Could you give an example of a case that could introduce a problem >>>> >>>> >>> >>> The most interesting scenario I had in mind was with recursive TAs. >>> Here is a simple example that would be useful to think through: >>> >>> -+---B1---+-- Area0 >>> | | >>> [R1] [R2] >>> | | >>> -+---B2---+-- Area1 >>> >>> Assume that there are two TA1 between R1 and R2: TA1 belonging to >>> Area 0 and transiting Area 1, and TA2 belonging to Area 1 transiting >>> Area 0. The event to consider is when TAs go up and then segments B1 >>> and B2 go down. Since both TAs are used in SPF, it is possible they >>> will use each other for resolution during SPF. >>> >>> It's a little hard for me to write down a full analysis of this >>> scenario during the IETF week :) I'd appreciate if you looked at >>> this, and I'll try to do so on my flight back on Friday to see if >>> it really is a problem. >>> >>> Cheers. >>> Alex >>> >>> >>> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 17 09:14:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12383 for ; Mon, 17 Nov 2003 09:14: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 <13.00C4A3E8@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 9:14:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60887320 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 09:14:20 -0500 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 09:14:19 -0400 Received: from cisco.com (dhcp-bru-peg2-vl28-144-254-0-171.cisco.com [144.254.0.171]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAHEEJ718965 for ; Mon, 17 Nov 2003 15:14:19 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <19899595280.20031110164510@psg.com> <000001c3a956$3ee7dc10$406545ab@amer.cisco.com> <16821525492.20031112204200@psg.com> <3FB4F77D.2040405@redback.com> <3FB898B5.2020907@cisco.com> <3FB8D3E5.5050704@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FB8D7BB.70902@cisco.com> Date: Mon, 17 Nov 2003 15:14:19 +0100 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Acee Lindem wrote: > > Hi Peter, > > I should have been clearer. After you run an SPF for a transit area, > you need > to check the TAs to determine if they should be brought up/down or > stay the > same (actually you could be smart about which ones you check). I'm > proposing > to augment this checking to assure a TA's status is not "up" if the best > path > through a transit area is not via a different locally configured TA in > another transit area. above would work if both TAs are configured between same pair of endpoints. I was wondering about the case, where two different TAs are configured on different set of endpoints: TA1 - endpoints: R1, R2; area 1; transit area 0; TA1 - endpoints: R3, R4; area 0; transit area 1; thanks, Peter > > > Make sense? I could be missing something since this is all based on > mental > simulation :^) > > Thanks, > Acee > > > > >> >> >> thanks, >> Peter >> >>> >>> >>> Alex Zinin wrote: >>> >>>> Sina, >>>> >>>> ->>The draft relaxes this and suggests that the TA can belong to >>>> ->>any area and can transit any area. This opens up a >>>> ->>possibility for TA1 that belongs to area A1 to transit area >>>> ->>A2 that has TA2. This means that it could be possible for >>>> ->>packets to be encapsulated more than once. It seems it could >>>> ->>also be possible to have recursive TA resolution, e.g. in the >>>> ->>case above, TA2 transiting area A1. >>>> >>>> >>>> >>>>> Yes, if TA1 has to transit over area 2 to go from ABR1 to ABR2 and >>>>> its >>>>> shortest path goes over another TA ( that is another TA belonging to >>>>> area 2 exist ) then the packet could be encapsulated / decapsulated >>>>> one >>>>> more time in the portion that TA2 traverse if they are multi-hop but >>>>> note that in any case the packet will be delivered to te remote ABR >>>>> and >>>>> there should not be any problem. >>>>> >>>>> >>>> >>>> In general, because VL in any area can use a VL in any other area, it >>>> seems there can be multiple (more than 2) encapsulations. This >>>> certainly has some TCP path MTU implications that need to be spelled >>>> out. >>>> >>>> ->>Seems that this needs to be given more thought. >>>> >>>> >>>> >>>>> Could you give an example of a case that could introduce a problem >>>>> >>>>> >>>> >>>> The most interesting scenario I had in mind was with recursive TAs. >>>> Here is a simple example that would be useful to think through: >>>> >>>> -+---B1---+-- Area0 >>>> | | >>>> [R1] [R2] >>>> | | >>>> -+---B2---+-- Area1 >>>> >>>> Assume that there are two TA1 between R1 and R2: TA1 belonging to >>>> Area 0 and transiting Area 1, and TA2 belonging to Area 1 transiting >>>> Area 0. The event to consider is when TAs go up and then segments B1 >>>> and B2 go down. Since both TAs are used in SPF, it is possible they >>>> will use each other for resolution during SPF. >>>> >>>> It's a little hard for me to write down a full analysis of this >>>> scenario during the IETF week :) I'd appreciate if you looked at >>>> this, and I'll try to do so on my flight back on Friday to see if >>>> it really is a problem. >>>> >>>> Cheers. >>>> Alex >>>> >>>> >>>> >>> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 17 09:40:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12925 for ; Mon, 17 Nov 2003 09:40: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 <18.00C4A40F@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 9:40:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60890053 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 09:40:13 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 09:40:13 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8182F86DAAA for ; Mon, 17 Nov 2003 06:40:12 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21721-01 for ; Mon, 17 Nov 2003 06:40:11 -0800 (PST) Received: from redback.com (unknown [155.53.6.19]) by prattle.redback.com (Postfix) with ESMTP id 62BFE86DAA8 for ; Mon, 17 Nov 2003 06:40:11 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <19899595280.20031110164510@psg.com> <000001c3a956$3ee7dc10$406545ab@amer.cisco.com> <16821525492.20031112204200@psg.com> <3FB4F77D.2040405@redback.com> <3FB898B5.2020907@cisco.com> <3FB8D3E5.5050704@redback.com> <3FB8D7BB.70902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FB8DDC7.6060907@redback.com> Date: Mon, 17 Nov 2003 09:40:07 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FB8D7BB.70902@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Peter Psenak wrote: > Acee, > > Acee Lindem wrote: > >> >> Hi Peter, >> >> I should have been clearer. After you run an SPF for a transit area, >> you need >> to check the TAs to determine if they should be brought up/down or >> stay the >> same (actually you could be smart about which ones you check). I'm >> proposing >> to augment this checking to assure a TA's status is not "up" if the best >> path >> through a transit area is not via a different locally configured TA in >> another transit area. > > > above would work if both TAs are configured between same pair of > endpoints. > I was wondering about the case, where two different TAs are configured > on different set of endpoints: > > TA1 - endpoints: R1, R2; area 1; transit area 0; > TA1 - endpoints: R3, R4; area 0; transit area 1; Seems like this could be a problem if R1 and R3 had physical connectivity in areas 1 and 0 and R2 and R4 also had physical connectivity in areas 1 and 0. What's more the packets would loop until the TAs went down due to hello timeout. > > > thanks, > Peter > >> >> >> Make sense? I could be missing something since this is all based on >> mental >> simulation :^) >> >> Thanks, >> Acee >> >> >> >> >>> >>> >>> thanks, >>> Peter >>> >>>> >>>> >>>> Alex Zinin wrote: >>>> >>>>> Sina, >>>>> >>>>> ->>The draft relaxes this and suggests that the TA can belong to >>>>> ->>any area and can transit any area. This opens up a >>>>> ->>possibility for TA1 that belongs to area A1 to transit area >>>>> ->>A2 that has TA2. This means that it could be possible for >>>>> ->>packets to be encapsulated more than once. It seems it could >>>>> ->>also be possible to have recursive TA resolution, e.g. in the >>>>> ->>case above, TA2 transiting area A1. >>>>> >>>>> >>>>> >>>>>> Yes, if TA1 has to transit over area 2 to go from ABR1 to ABR2 and >>>>>> its >>>>>> shortest path goes over another TA ( that is another TA belonging to >>>>>> area 2 exist ) then the packet could be encapsulated / decapsulated >>>>>> one >>>>>> more time in the portion that TA2 traverse if they are multi-hop but >>>>>> note that in any case the packet will be delivered to te remote ABR >>>>>> and >>>>>> there should not be any problem. >>>>>> >>>>>> >>>>> >>>>> In general, because VL in any area can use a VL in any other area, it >>>>> seems there can be multiple (more than 2) encapsulations. This >>>>> certainly has some TCP path MTU implications that need to be spelled >>>>> out. >>>>> >>>>> ->>Seems that this needs to be given more thought. >>>>> >>>>> >>>>> >>>>>> Could you give an example of a case that could introduce a problem >>>>>> >>>>>> >>>>> >>>>> The most interesting scenario I had in mind was with recursive TAs. >>>>> Here is a simple example that would be useful to think through: >>>>> >>>>> -+---B1---+-- Area0 >>>>> | | >>>>> [R1] [R2] >>>>> | | >>>>> -+---B2---+-- Area1 >>>>> >>>>> Assume that there are two TA1 between R1 and R2: TA1 belonging to >>>>> Area 0 and transiting Area 1, and TA2 belonging to Area 1 transiting >>>>> Area 0. The event to consider is when TAs go up and then segments B1 >>>>> and B2 go down. Since both TAs are used in SPF, it is possible they >>>>> will use each other for resolution during SPF. >>>>> >>>>> It's a little hard for me to write down a full analysis of this >>>>> scenario during the IETF week :) I'd appreciate if you looked at >>>>> this, and I'll try to do so on my flight back on Friday to see if >>>>> it really is a problem. >>>>> >>>>> Cheers. >>>>> Alex >>>>> >>>>> >>>>> >>>> >>> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 17 17:11:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08958 for ; Mon, 17 Nov 2003 17:11:31 -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.00C4AF82@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 17:11:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60921266 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 17:11:38 -0500 Received: from 195.121.6.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 17:01:36 -0400 Received: from SIEM (ipd54bba92.premium.planet.nl [213.75.186.146]) by smtp07.wxs.nl (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HOI00IOJNUFY2@smtp07.wxs.nl> for ospf@peach.ease.lsoft.com; Mon, 17 Nov 2003 23:01:36 +0100 (MET) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_Eaz4PIFJ+OMlLifwSTArLA)" X-Priority: 3 X-MSMail-priority: Normal Message-ID: <003a01c3ad56$58bf2360$0201a8c0@SIEM> Date: Mon, 17 Nov 2003 23:01:25 +0100 Reply-To: Mailing List Sender: Mailing List From: "C.C.Boot" Subject: OSPF - IP Multicast interaction problem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_Eaz4PIFJ+OMlLifwSTArLA) Content-type: multipart/alternative; boundary="Boundary_(ID_blnKO2LrSwn12H5BASglNA)" --Boundary_(ID_blnKO2LrSwn12H5BASglNA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT From: Teco Boot To: John Moy; IETF OSPF working group CC: All interested specialists on OSPF and IP Multicast protocol Subject: OSPF - IP Multicast interaction problem Date: 17 November 2003 ================== Dear mister Moy, IETF OSPF working group members I want to inform you about an OSPF - IP Multicast interaction problem. We did have some problems during our "Proof of Concept" testing this week, caused by RPF (reverse path forwarding) checks, performed by PIM and / or multicast packet forwarding code. -------- Problem description: The RPF problem was caused by settings on some of the router links, the OSPF metrics were configured highly, as the config was left from a previous test. The configuration was absolutely valid for OSPF and was preferred for the previous setup. As soon as we saw this configuration, we adjusted it and our problem disappeared. But I was not amused about this problem. I made multiple designs making use of a permitted technique in OSPF: we set the OSPF metric on values that are related to the interface bandwidth and / or CPU power of the routing device; metrics on interfaces connected to a certain transit network could differ. Here some real world examples: 1) Token Ring and ATM backbone (old technology but it is a real world example, I made the design myself). An 4Mbps interface would get a medium to high metric related to 16Mbps and a high metric related to high speed LANE ATM interfaces. 2) Ethernet VLAN environments (todays technology, so interesting to mention). It is likely that redundant VLAN backbone segments are interconnected using layer-3 switches and possibly WAN routers are connected to multiple backbone segments. The WAN routers should not handle VLAN backbone traffic, so the OSPF metric on the WAN router interfaces would get high metrics related to the layer-3 switches. 3) On Frame Relay or ATM networks, using partly meshed structures and unequal access bitrates, a network designer configures the OSPF metrics with respect to the available bandwidth. This is especially true if other communication means are in place, e.g. ISDN, satcom or microwave links. -------- If transit networks are configured with unequal OSPF metrics, asymmetric routing is likely to occur. As an example I studied the network as described in RFC2328, figure 2. I calculated traffic paths from N1 to N7 and vice versa. I included two drawings below, depicting asymmetric routing. Avoiding asymmetric routing is generally accepted as a design goal and it is mandatory for every IP multicast capable network. On the other side I mentioned a few example networks that benefits from unequal OSPF metric settings on transit network links, which could introduce asymmetric routing very easily. As I kept thinking about this problem, I came to the conclusion that the IP community running OSPF (or a similar routing protocol) would benefit from an improvement on asymmetric routing probability avoidance. An easy to define mechanism could take the average (and round downwards) of the ingress and egress interface metric on each transit link. Implementing is harder, as each router in an area must have an identical path calculation algorithm. So the implementation must support backwards compatibility, e.g. the new algorithm should be enabled per area and a router LSA option bit could be used to signal existence of old style routers. Now I can formulate my questions: Is the problem described above well known and documented in an RFC or Internet Draft? What is your opinion on this issue? Could it be fixed in OSPF? When could the problem be fixed, what is your opinion on this? Your response would be very welcome. If you have needs for any more explanation on this issue, please let me know. Regards, Teco Boot Mail: c.c.boot@planet.nl Figures: Taken from RFC2328, figure 2, page 18; route from N1 to N7 and vise versa. (figure 1) N1 to N7: path will be: N1 - RT1 - N3 - RT4 - RT5 - RT7 - N6 - RT8 - N7 path cost is: 1 + 8 + 6 + 1 + 4 = 20 (figure 2) N7 to N1: path will be: N7 - RT8 - N6 - RT10 - Ia/Ib - RT6 - RT3 - N3 - RT1 - N1 path cost is: 1 + 5 + 6 + 1 + 3 = 16 --Boundary_(ID_blnKO2LrSwn12H5BASglNA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
From:     Teco=20 Boot

To:       John=20 Moy; IETF OSPF working group

CC:       All=20 interested specialists on OSPF and IP Multicast=20 protocol

Subject:  OSPF =96 IP=20 Multicast interaction problem

Date:     17 = November=20 2003

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Dear=20 mister Moy, IETF OSPF working group = members

 

I want to=20 inform you about an OSPF =96 IP Multicast interaction problem. We did = have some=20 problems during our =93Proof of Concept=94 testing this week, caused by = RPF (reverse=20 path forwarding) checks, performed by PIM and / or multicast packet = forwarding=20 code.

 

--------

 

Problem=20 description:

 

The RPF=20 problem was caused by settings on some of the router links, the OSPF = metrics=20 were configured highly, as the config was left from a previous test. The = configuration was absolutely valid for OSPF and was preferred for the = previous=20 setup. As soon as we saw this configuration, we adjusted it and our = problem=20 disappeared.

 

But I was=20 not amused about this problem. I made multiple designs making use of a = permitted=20 technique in OSPF: we set the OSPF metric on values that are related to = the=20 interface bandwidth and / or CPU power of the routing device; metrics on = interfaces connected to a certain transit network could differ. Here = some real=20 world examples:

 

1) Token=20 Ring and ATM backbone (old technology but it is a real world example, I = made the=20 design myself). An 4Mbps interface would get a medium to high metric = related to=20 16Mbps and a high metric related to high speed LANE ATM interfaces.=20

 

2)=20 Ethernet VLAN environments (todays technology, so interesting to = mention). It is=20 likely that redundant VLAN backbone segments are interconnected using = layer-3=20 switches and possibly WAN routers are connected to multiple backbone = segments.=20 The WAN routers should not handle VLAN backbone traffic, so the OSPF = metric on=20 the WAN router interfaces would get high metrics related to the layer-3=20 switches.

 

3) On=20 Frame Relay or ATM networks, using partly meshed structures and unequal = access=20 bitrates, a network designer configures the OSPF metrics with respect to = the=20 available bandwidth. This is especially true if other communication = means are in=20 place, e.g. ISDN, satcom or microwave = links.

 

--------

 

If=20 transit networks are configured with unequal OSPF metrics, asymmetric = routing is=20 likely to occur.  As an = example I=20 studied the network as described in RFC2328, figure 2. I calculated = traffic=20 paths from N1 to N7 and vice versa. I included two drawings below, = depicting=20 asymmetric routing.

 

Avoiding=20 asymmetric routing is generally accepted as a design goal and it is=20 mandatory for every IP multicast capable network. On the other = side I=20 mentioned a few example networks that benefits from unequal OSPF metric = settings=20 on transit network links, which could introduce asymmetric routing very=20 easily.

 

As I kept=20 thinking about this problem, I came to the conclusion that the IP = community=20 running OSPF (or a similar routing protocol) would benefit from an = improvement=20 on asymmetric routing probability avoidance. An easy to define mechanism = could=20 take the average (and round downwards) of the ingress and egress = interface=20 metric on each transit link. Implementing is harder, as each router in = an area=20 must have an identical path calculation algorithm. So the implementation = must=20 support backwards compatibility, e.g. the new algorithm should be = enabled per=20 area and a router LSA option bit could be used to signal existence of = old style=20 routers.

 

Now I can=20 formulate my questions:

Is the=20 problem described above well known and documented in an RFC or Internet=20 Draft?

What is=20 your opinion on this issue? Could it be fixed in=20 OSPF?

When=20 could the problem be fixed, what is your opinion on=20 this?

 

Your=20 response would be very welcome. If you have needs for any more = explanation on=20 this issue, please let me know.

 

Regards,

Teco=20 Boot

Mail:=20 c.c.boot@planet.nl

 

 

Figures:

Taken from=20 RFC2328, figure 2, page 18; route from N1 to N7 and vise=20 versa.

 

(figure=20 1)

 

N1 to=20 N7:

path will be:  N1 = - RT1 - N3=20 - RT4 - RT5 - RT7 - N6 - RT8 - N7

path cost=20 is:         =20 1 +        = 8=20 +   6 +   1 +       =20 4     = =3D=20 20           &n= bsp;   =20

 

 

(figure=20 2)

 

N7 to=20 N1:

path will be:  N7 = - RT8 - N6=20 - RT10 - Ia/Ib - RT6 - RT3 - N3 - RT1 - N1

path cost is:         =20 1 +        =20 5 +          =20 6 +   1 +       =20 3     = =3D=20 16           &n= bsp;   =20

 

 

 

 

 

--Boundary_(ID_blnKO2LrSwn12H5BASglNA)-- --Boundary_(ID_Eaz4PIFJ+OMlLifwSTArLA) Content-type: application/pdf; name=moy.pdf Content-transfer-encoding: base64 Content-disposition: attachment; filename=moy.pdf Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjEzIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAxNSANL0ggWyAx MDM1IDIyOSBdIA0vTCAyMjk0NyANL0UgOTQ0MCANL04gMyANL1QgMjI1NjkgDT4+IA1lbmRvYmoN ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTEzIDI2IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA4NjcgMDAwMDAgbg0KMDAw MDAwMTI2NCAwMDAwMCBuDQowMDAwMDAxNDcxIDAwMDAwIG4NCjAwMDAwMDE2MDYgMDAwMDAgbg0K MDAwMDAwMTc4NSAwMDAwMCBuDQowMDAwMDAyMzM3IDAwMDAwIG4NCjAwMDAwMDI1MTcgMDAwMDAg bg0KMDAwMDAwMjUzOCAwMDAwMCBuDQowMDAwMDAzNDI5IDAwMDAwIG4NCjAwMDAwMDM0NTAgMDAw MDAgbg0KMDAwMDAwNDMwOSAwMDAwMCBuDQowMDAwMDA0MzMwIDAwMDAwIG4NCjAwMDAwMDUxNTkg MDAwMDAgbg0KMDAwMDAwNTE4MCAwMDAwMCBuDQowMDAwMDA2MDYwIDAwMDAwIG4NCjAwMDAwMDYw ODEgMDAwMDAgbg0KMDAwMDAwNjkwOSAwMDAwMCBuDQowMDAwMDA2OTMwIDAwMDAwIG4NCjAwMDAw MDc4MzUgMDAwMDAgbg0KMDAwMDAwNzg1NiAwMDAwMCBuDQowMDAwMDA4NzM2IDAwMDAwIG4NCjAw MDAwMDg3NTcgMDAwMDAgbg0KMDAwMDAwOTIxMSAwMDAwMCBuDQowMDAwMDAxMDM1IDAwMDAwIG4N CjAwMDAwMDEyNDMgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAzOQ0vSW5mbyAxMSAwIFIgDS9S b290IDE0IDAgUiANL1ByZXYgMjI1NTkgDS9JRFs8OGQ2MWY1ZDRmNzAzNGNlNjVhNTMwYzUxNjU4 MWJhMWQ+PDhkNjFmNWQ0ZjcwMzRjZTY1YTUzMGM1MTY1ODFiYTFkPl0NPj4Nc3RhcnR4cmVmDTAN JSVFT0YNICAgICANMTQgMCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9nIA0vUGFnZXMgMTIgMCBSIA0v T3BlbkFjdGlvbiBbIDE1IDAgUiAvWFlaIG51bGwgbnVsbCBudWxsIF0gDS9QYWdlTW9kZSAvVXNl Tm9uZSANL1BhZ2VMYWJlbHMgPDwgL051bXMgWyAyIDw8IC9TIC9EIC9TdCAzID4+IF0gPj4gDT4+ IA1lbmRvYmoNMzcgMCBvYmoNPDwgL1MgNzMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAz OCAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgZmBg4WZgZWAQN2HgYUAAHgYWoCgLA8cMhqbAXwwMHg0M DIwd087pB/JMO5YfwMDBwOSSwcDokgGWBQJ2BobgY0BaDIilwCKiDFx67UpVwuoHeGcwXGzgWcBw 7QDPHIa7DLw5DDnOEx1C9bkCQOoAAgwA8NgXzw1lbmRzdHJlYW0NZW5kb2JqDTM4IDAgb2JqDTEy NCANZW5kb2JqDTE1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxMiAwIFIgDS9SZXNv dXJjZXMgMTYgMCBSIA0vQ29udGVudHMgWyAyMSAwIFIgMjMgMCBSIDI1IDAgUiAyNyAwIFIgMjkg MCBSIDMxIDAgUiAzMyAwIFIgMzUgMCBSIF0gDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9D cm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE2IDAgb2JqDTw8 IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAxOCAwIFIgPj4gDS9FeHRH U3RhdGUgPDwgL0dTMSAzNiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTkgMCBSID4+IA0+ PiANZW5kb2JqDTE3IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1 IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTY2 NSAtMzI1IDIwMjggMTAwNiBdIA0vRm9udE5hbWUgL0FyaWFsIA0vSXRhbGljQW5nbGUgMCANL1N0 ZW1WIDAgDT4+IA1lbmRvYmoNMTggMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1 ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxNTAgDS9XaWR0aHMgWyAyNzggMCAwIDAg MCAwIDAgMCAzMzMgMzMzIDAgMCAyNzggMzMzIDI3OCAyNzggNTU2IDU1NiA1NTYgNTU2IDU1NiAN MCA1NTYgNTU2IDU1NiAwIDI3OCAyNzggMCA1ODQgMCA1NTYgMTAxNSA2NjcgNjY3IDcyMiA3MjIg NjY3IDYxMSANMCA3MjIgMjc4IDUwMCAwIDU1NiA4MzMgNzIyIDc3OCA2NjcgMCA3MjIgNjY3IDYx MSA3MjIgNjY3IDk0NCAwIA02NjcgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3 OCA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiANODMzIDU1NiA1NTYgNTU2IDU1NiAzMzMgNTAwIDI3 OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCA1NTYgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rp bmcgDS9CYXNlRm9udCAvQXJpYWwgDS9Gb250RGVzY3JpcHRvciAxNyAwIFIgDT4+IA1lbmRvYmoN MTkgMCBvYmoNWyANL0NhbFJHQiA8PCAvV2hpdGVQb2ludCBbIDAuOTUwNSAxIDEuMDg5IF0gL0dh bW1hIFsgMi4yMjIyMSAyLjIyMjIxIDIuMjIyMjEgXSANL01hdHJpeCBbIDAuNDEyNCAwLjIxMjYg MC4wMTkzIDAuMzU3NiAwLjcxNTE5IDAuMTE5MiAwLjE4MDUgMC4wNzIyIDAuOTUwNSBdID4+IA0N XQ1lbmRvYmoNMjAgMCBvYmoNODEzIA1lbmRvYmoNMjEgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCAyMCAwIFIgPj4gDXN0cmVhbQ0KSImUVE1v2zAMvftX6CgNs2pZtmRn6GFt 16EDuhWIgR2KHvLhpu5SK2icFv0j/b2jRMppcisCRJJFPj5SfDxrkpOmyZlizX1Sy9qwDH5hY40s 4b+2UptMs+YpOTnflmyxDSYZ2y6Sk59TxVbbJGPNwv+9JpyJ5hG2KXjnpgTYiyTNZJapMtjALqu8 4S3fzFatSJWShk+Yoh0Td82vpMhkkSsLQUb3egxxy5VNRQr4XCna5OCe8wxoBv80AthCmiwvPEzg ONJTUpXGjPA+v0WSy7qGxEOMy2cnlJaWP4k0z2GdsAaCGN4Kz3Ph42ruBJLWAMHPnBswfvMFYfM8 Ju3T97Aew8oaHMFA84lQWQBIC1VlEOWXSCvIxz307NrnBJcurJq/CVWC5zc4allydvUjgl2KtJQV Z39EauFmehM/hKq8umdYK0D6B6n4qF2/Yqtnn0HJ3W5zxDmU4pafn09CpMBOV7UC4+9rkdZ8zTq/ 9D6Fgg9tQPKFCeetz0DzAZzxI5Av+BIvGd1u2gVuAtIMLwN4J/QRBJ2Y6wkL8zQxz5rynPVL3Fzd 4Hq9I4f10FG4WYRGiw1Rd2RIER1Zu/VRaQw9p9I1Pud0N38E1mCLCRk+YNWQVF1VPJCtkaxvVSYg 8HsIaPEAfImqHakaogqArOsHwgwltjywDmULPjGyJw8FdD3bkIWbR9jWt3FJ8sL+L4p9/yszqpMy u5gN7SR4h1R0nlewA0n9dkGqlr8EzILPfQOEZ8izjO70x0AktOMhAVX1AU2B/XYKpZCKn55+aoPr +EwfRD4+2ihBTZm1s2dULwsJwLtD00lsO6wiPGc0ucbeUF5+Bpav4Sn0Xn4W5WeoLTWf+oaw/CZ+ RhGKOowLoKQ4YaMc1Qc5ah6jgSojudb3SDzMI7FA9jDvwwF89MIo6/jWvg5X7HVGnQUsB4dEu/6e PjlUJUkECVhK503kFgaM25H05lFBuyGKcVQpnDM+SvX9sxrtRo7tASEaGouDWdHth8So7XmM0MYc JBozASfF/8LwNaHOOKKW3ZI9kA8FeYljLM4vqk0EjK77mPtgcXyJu/8CDACYqp7YDWVuZHN0cmVh bQ1lbmRvYmoNMjIgMCBvYmoNNzgxIA1lbmRvYmoNMjMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCAyMiAwIFIgPj4gDXN0cmVhbQ0KSIl8VE2P0zAQvfdX+GijJuS7LTcEQmIl RMXmtruHbGPSQLEjNumK3wE/mPF8pO0uSw9N4hm/92b8xvXVIlFRGqdlVan6/SJK4iRJN6reLfAt U/Xj4ka3008TVXGme2eiNNOd8vicTKI5on7Tc2uyuJBF779CXh7Cp7d33u1MtIo32iLIACDjH0YZ 7QPFRogFQhOt40q7To28fw/pPScpBHg0G6AkMPvdRFmil4opmolTbavuIVTEqf5lUuT6sv0Ae1YA r2418bNuCxxHyx8CQGRDMwtRUpI/teEROACw4c8W9a9A/63hClnY3vILCWaSpTJ39dWifkUnkYWD uNEDSck1EeZACOEUOEvA/oFlFVxhmkmFKbdn+/ETvTSOw616rTxDUkgwJgI+jD2oW+vmIfyPamjw E6VC2FLWqJ7pQchwHjm3IIcWCG3HT4VgvrXxXG2CjgtmA0H1N1yC+oucGhDhz4DQKLrcQ+nk4aI4 eThbiYfZwluQs9KeOrTWBxtKLoOaNlguHNKOHpjYD2PvOdeF6tb6DTFfzMs/dL8wQjVbbW/Jd2Vc ajXInKAsFlWEUyFPN2Z2xmxoHrzw/7K1JRJGS/zau06waHodRCUzWFjIw66zeR1BsuiECFHzeMqM qAPNaW9ykO0uPU2piPM5LGX62kQbyJ77cOZBoh/lvuGqRbiMenI+qU9mJp9bX1Hr8VzBpI5KApUd 3WdVaB1y72FON7rbQxlZSn0s4chResX6cBjC2UAh6IyCnEz+x+8zhvlqCieWQEx2HwKTpTVJH5lH vlmdN2k6D/hKq4YNA7qPKNgTzMT0s0DLb2Osgu/WwXX/6QJfabDknVR2Lv8CvLnnN38QXpZvn3SP MI4CcAiS8fa5PC++5EhWSTXl1AKwBjqm1NfkFQDlWyzX7en2T6nJOYnMZLBKbQXV8oKszxgv0Aaz Dk+SjwTe+0lo+Glp78hQ0xCTtLcPeGHmc6L3TjWymdRbiTXMQvUoAdsTdi+7dozkRHjf8caJ5TZy c+XaLWcWc/dXgAEALszIcQ1lbmRzdHJlYW0NZW5kb2JqDTI0IDAgb2JqDTc1MSANZW5kb2JqDTI1 IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjQgMCBSID4+IA1zdHJlYW0N CkiJdFVNc9QwDL3vr9DRZkiIs8l2t5z4GIYyw9CBcGp7cBp3N2VxltZp4d8jy1LaFHqK4khPT0+y 0nxaFJCZ3FTVCpr3i6zIi8JsoLlckFVCc784U7a71tk6X6nxVmdH+UYF14HOTKn6AJYMzwfDeKOz VV4qOLAx0HmrC7VPIA7Nn/EwXyroeoa0eHog14OzGGrW+Nl1OeiLRljWK2JZEL9ITYFurhfNi+eI vx0DnCDWMhIi8Hu9yStKxnnBJ954grUgr7LCxFIo1mlbLoweAcJOKCfEqc5W6hOQHE5AY5lGyYnt HEwpoiKhP+xdwukcw/YJZuslzRSdwH7ga4FeSyzEb2GiCsPVrFQLB8fcBCEFBWpflFWUK6NwZ9jW S8ytdp4oHKlfo6M+GQW9F+tLTLdU33S2QZfTDzqrke3xg7zYNvG9jXD4VuBLSB5h556B4DqrKYDI I2kiBYNPAHd2n9iNjuAF1nICy2EOxEhwHGUZXDh2EIYHZmmofSAhp1AGuuJTS4QctJYxfMfGfd+F nRQ/U9isp9k0fKnwyrwiRPQdKAUa7/CkQjFOdZnX6jvEK2GwuwM/o8C1cuLOLUeL8hqaA/44jIH6 WMcp4RFjn7uo6VEeexPre83Sl/weGEG8btMjtkAQGSgIE+FhBVhi+H3w3rE5LQ8U3jIOzPgwZuxC hOwlGwgx6xm+D1L/v/NMYi+T2N5JS9OEDrPG0o2KINTYYdwzwa6Xll/9dyDySBCX2Ec3H7U095zj yVRPU2n3j6/MnBDPagfud0SygoHLgqCPH29F3t1Pt+JsZSZVzCRLlWQx5zomrBQ0yIX6pEnppAjO g4evvd/SSONesZ6tDt5IxGdo+dDy8xK3zANEO3gH5yrlGdgFFU4NYV1iEJZscPdMLsOWt9YfbVZ8 zdsxTD+euIbX1Pq07W5SCsYTMns9X/5lkrpU6R9TswNLHWcriV1HsV+muJP0kA9xi8dlQRubauy3 uJwu/gowALOiqrINZW5kc3RyZWFtDWVuZG9iag0yNiAwIG9iag04MDIgDWVuZG9iag0yNyAwIG9i ag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI2IDAgUiA+PiANc3RyZWFtDQpIiZRV TW/TQBC991fMcRfVlr/iJMdIFAnUFiSicmg5OPE2Nrh2RG2q/nvm0w0VPXDJjndn5817MzvZfjrb vju7dQ8+yop44Z59tnKPPlrFqQs+SrM4c909GnlcuDvvoxLXGL9xgU0Phfpc+SjBrd1R7wLtu7Yf 9Wqg88z9kgAWsNorkrg/+TX6DOI6GbrP8bcWj0MYxajAMg51O5kN4wBNSzFX7tC8uEjEUdFbRQX9 1uOuGo1xjYHUhLQ0irujWsax6muozO8/cP33LcuOp0mSrmC7P2Mrhe0T1oLdSf4EfzWrNF5bVmQq 2oLQMJsl4h71KITanC7V2PgMXa8vfLQmkTZb3F+idQVWIENT6HvdpPpQ7KAYMcy5J5w1JYx8tj9m Olk+0ymFTiZtUzq4GBtWSyUvBK50vVX15lLPN9eyEXrd+N2q76Ab/QMbS3QZuR65gzsnPsSJXGv1 rXR99uki1vZGd6FeWjJ72W56g+jMOPx9/1zvgQYyt1nN8hU//VJ3za41agfqWmkZZoOVXbuhN9Vi +Kjq8IEl37U/8QqFDR3VNbXsZlpNNUq1EkDAtCiwHu+1SHON8pOWy/EtTZJV6upKySCWliWdy7Lj h+skg9Tthj6oB2viwkH4FFYdfCsGMauUiy6pgXPIoe8DG7NPDRNH4IZfuv4gKXQVI2REW17LaaxI llw2KSlO9AlXjNGODNEETU1zx9d8VHOQi3yu6JTMruNAKwMFz97ffFTQJ72z3F2fqr4oX1RP1yS7 io1zbhqDmvy81iYStj3sZYdby4km9C0Tap5PDuQV5DgtE9eJZtgox47EosZLHOxkYKKpQbhsXDRQ YKtXrvWiPR7yiCDDAtsJhzS6KFvmWiDXt8no2gyTZlMDNxeSStwITSXcailnOJ0A3Gg6aG6l214l PipYda+cbaVCFcb0XDk8mpoox4hEPtN35r7Swyndlw8+WtBgnEWgBBWg1VAw9HRVVJ+FWKy07P+W Yu71jGPqrqVqtIIpRv9/hdZ86kQYwL889YdGxwAxPDRzA7yZs8W1rqIewb8T6h6U948AAwBeONHK DWVuZHN0cmVhbQ1lbmRvYmoNMjggMCBvYmoNNzUwIA1lbmRvYmoNMjkgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyOCAwIFIgPj4gDXN0cmVhbQ0KSIl8VUtv2zAMvudX8CgN sWDZjuMcBxQDOmAPrL61O7iJlmh17a6RG/TfjxQpbx6w9lDJ4uvjx0faj6v23SrLTZ4XBbT7Fd5s uYH2srpV4eSg73RWVKZSr9puzE45jcqletZZbTYq46PkR9C2UGfUp4+L3hmrfNjrrDGFOunMFvjs zvxtQH9vY/A8hqWI6KD9OeOxO8GT24LxlHea4hUKvuhsi+egcwUfdLZBDM8s6h4jXgwE35yAtwQ+ 2o2iBYRGvW/x2JpafYLBBbyXKLoknQdKhNLZYtprlJLdJN9+OMJTJ5qhjzlv5zAzBj07OLkDyDWw LzGeUGe/EEwicaLPYLvhwJdpcPH8NfF7T4TWCjrxIsdfsZOfex8SSyE5X3MdcsDQtqpqaK+Q6e7/ hMAhmfrj4BKfEnSMkIYfYuqPjPHfhKixpIQ3Otsh+q9SxQV1Ca3fL/Og1qqU57zDCVDNNku6n1zi FMLIvFFQZuyFRV30sFV9dx/fe12iW1G6j7SUG5Pv6gpyooVGI7fUlFm8NtyVWJiLLmxEhCNSqQNB 1zY3DXY9ujJ8h5ZSrPlNVM+auhOWXzFylkJTXTZ1rMtyTHMrY5pGKuZMF9/JsPXUmDaNLgSZ2inN ooyt53oh+2OQ28mJLojPkXUfo2mtuEw1NqMXhY4Vgh8HSFLXDYINOvEn9PoBnhJI0sBqiB+3BmcE xdHAtVxvdIHcXH1ew3kZL+FLMWXG51aqkesSTffyPPJiShS9oLBJqHrPWIYHWWJpWdFgbtRbK4sK UpX0fquy+EdlzrKlDasvho2LOte05Jpec0nKVLRSMZW4UOfRLNNoljyamFVUEa5pBRI5ahySM5zH JJJlcvHJ14n4xO6bhsiMVY4XDHHV07RaGrobHtRaltKj/Dg4Nk5YY08wmLg4MY3uLBBfddHgwY1U ve0B5GucAi5cQQOes4x908Tq/iFA3Igs7mO0CGOyHaPf+G9iVQlhBCfW67cAAwBG+ZjiDWVuZHN0 cmVhbQ1lbmRvYmoNMzAgMCBvYmoNODI3IA1lbmRvYmoNMzEgMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCAzMCAwIFIgPj4gDXN0cmVhbQ0KSImEVU1v2zAMvftX8CgNtWApiu0c 9wm0h67YfBt6UGo19ZbaWeO0678fJZLuigEbCtS29Eg+Pn6kuygqKK2x67qG7kNRVqaq7Aa6m+Kb envUZWM2CsIIurROxV90EO516bxZqcM+wjkwbEaMcerUZ+wQ6QnzHdnCGBNihZCn6UGXNb78QD8V +pdAfeS3G3owbNjGnhgMzOTLJ12uzVq9dyuXD9ozuGXvg14Zr3YnNo5Ewxk4ZwCw96Artef3U0bt ddmaWoVZ4s3sJIjz10HYGA5hvpMc9HV3UXRvUD/Bso9JW2esEu3g0sI8wWUDIYcaOeTjwF4j0uOj iC5si0YcJGAyMBDZEWFssc+kuACYwqI3hkTkBL34oZBPeoN48bM7UjW2kWWY/gCdEZM+HqgOHHEe xvy901zGlVPP2rUYVPKUZ0oH5VybdrEGUeY0LyTMImCVuhD/PRUoQ/c9HeX2dD5fpEZt0i026mOy 9moacurYF4N26H/kr51Gw7UQxDek2JgmUcP7lim2qVUSjoreZJrJLfB3orm4hOHItzs+imNkYOCT fWaBaro0GM/arvGShAzsmx/xMEfhnmlmz4SkqWipUhvsoB0PwW5aAoG8SRcNMz/Fl+QYKMdRW4t6 92FOs7iq8OY5C/+xKywMUHjrjW/BWSwQ+MbYGtCwcfAQi9viXVdszKaGCv/yi6/RnUd4Y1xbraC7 513SLMWiWtGYYm9VPBkK4mNqh0Zxl9ukVJ0454FVVzo1L7VFucIuqV3z185ydonjKRAlvE6TnULt ZyqnVSSvVTPIwSFss3yIwjXFr5HsaIZ8HgPs1FxhT4sLv03aecj0c8rAp4ZLp7jzIsk/0fZ7ccf2 wBzSGklTRehzENJxnIdpYdJD4O3maZ0Zx3xe9nJORMzTXpZ162XdvrA+IsHADbKNSxgJMczMjjSn Hwjvs9iy1bxkMqVG2ixqw2mMP08hb5B20eVratxWXeWt3aiXNFlj9iUVEnXkWsbO0SQ7JfymEcQ2 MGJ8hSB9OdV/KAL7YVzUIdMzIImlgELuTtpmokgnaR0qpfxOzYs+dN2f2IxrHY4cLq3LRb7/CaOv fwswAN85v2kNZW5kc3RyZWFtDWVuZG9iag0zMiAwIG9iag04MDIgDWVuZG9iag0zMyAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMyIDAgUiA+PiANc3RyZWFtDQpIiWRVTU/j MBC991fM0V6RKN9pj0irleCySOS2cHAb0wSyTsU6Rfz7HXtmQoFT7PH4vTdfTne7ySDJ07xuGuh+ bpIszbKihe6wwVVeQfe2+aNeddKqefGj00lepFt1hLNFY75Lc/Wu8zqtFFjzTyfbtFWjTnZomHRS 5Gkt5yluFejH7nbT/UDSwBDQ0dY9B1OkzndMneUFcV8japvuFNzAC0Jkyp48+GEMXI1yOlNkHnWJ LO4IJmhUe5SLizJFUj9E0yhIJ5Te4MG8nwjF/kWIKi3VFbIcyMtojDRXcmKRCPyMWFY85ogaU6LY NC3MQWpmOsRLJCoouhBk4eYu5KpRH5BZYETmcmVeHCkZJR5MaFAPoQDb6EA0VB2sze8AVqh7wr77 pZMa67DmnmpcroluKNEPKmSlCWFlqP2VdmAglrUMIbEmLPFk5Jy/ku4GZRwhCjnJkZ8PBBEzFluj VA+aAaLvm94J8XLh1NPp3jo22idh8SBLodF5jtJEIhgHI+Wy/ZBytnJunQfR44gZQgcXYfWuixbb XHzXO+TnGW3ksC5yEHpffUvA3jDRPs5GrqZQzKJGyDgd2y/F+T4F5kzdRn3Vx7Vx3DU2Jb5rR19L cayNQr0307fnFAYsGiELl03OmINxMi9yujbpMvXgDU9jnAscCurws64wPMsDRrajBeotMbgeZALj fnFc5572b056AmM1SMDePS5ZE3UPxjZLNFFEzCI9aFV18aAVaz5ryic2aQStlY3tXSj+UBwYLWqy vDyGspdKLtDuy7XRUf+v5+z9xFZzIEdJdiN+nh1HdoDZ4VPKmwE8TXmD1WYq7PyYninWD7vthewp 3Aj0abIri/NhIEfROXBM5pPK3vLiirAlCXLrQhA7yrzXSq4C/x1KdVmGT/+Vai1Dy23tgB6SOFt4 uSZhiEYBbMNzEPZRSUUvKA73YM6WpXLTjz0DWK5EyynFFpp4Hg09vAFejgh94u3Cx5Muwi9gBaKH PNwzE03wcWbdozgNojiFe/pPkC4xr0XZBonGIyh5fESKD1jzNVLeLqeTMGL9H/8LMAB70MliDWVu ZHN0cmVhbQ1lbmRvYmoNMzQgMCBvYmoNMzc2IA1lbmRvYmoNMzUgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAzNCAwIFIgPj4gDXN0cmVhbQ0KSIl0Uj1PwzAQ3fMrbrQRseIk TRs2JBhAiIVsFYPTuG0g2KV1VPj3nONzCgOLfb6Pd++er3lMmqskzUSW5RKaTeItWUJzTtasVRue roRk7zzNM5GzM6/xVEeeVqJk3SlEgbIsT33SByaXYsEOyvVt70MrNvQOvQv0fnNZsWueSgQAvHKm BV4FPncC3N67EESD0WSeQZE18ALPncX+coVYvdvHZkBc9nYcOkqHVkMEMaqNINHVwUHTJIFInEsr epsZKTIASrGjm2ufKPbC0xpHvQX+2kyqrpk9OBLAmoDZ9u6XXFPdOISUDvnGNiONo2cGzgYACvRB CjNLA/qLIpThSFVtqJ8GuyUf2D+KdnCpuXwS0dL/j05VIv4mzZ1Ne+RXCH3NG5oYl2VZQXMXVk1W cdWyOqzas2ckxXJasSWDB6/SUlRMkd/AdiJSo26ZKNiRV9h6+n5UUDkNaBfe58n7jfgcqVSfApTr rSHzJpC9b5IfAQYAZI6wsQ1lbmRzdHJlYW0NZW5kb2JqDTM2IDAgb2JqDTw8IA0vVHlwZSAvRXh0 R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIgL0lkZW50aXR5IA0+PiANZW5kb2JqDTEg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDEyIDAgUiANL1Jlc291cmNlcyAyIDAgUiAN L0NvbnRlbnRzIDMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAg MCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yIDAgb2JqDTw8IA0vUHJvY1NldCBb IC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDcgMCBSIC9GMiA4IDAgUiAvVFQyIDE4IDAgUiAv VFQ0IDkgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzYgMCBSID4+IA0vQ29sb3JTcGFjZSA8 PCAvQ3M1IDE5IDAgUiA+PiANPj4gDWVuZG9iag0zIDAgb2JqDTw8IC9MZW5ndGggNjA1NiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibRXbW/byBH+rl+xHykrpLivXF4/XJGkV+SA uoVPQFHEB0O25ditLRln+XIF+OM7b0suXSmWncQBIg53d16emXl2+HYxmS8WRmm1uJq0VRtUDf/o oQmVh//bprKhtmpxN5m/e/Dq4oG21OrhYjL/6y9afXqY1Gpxgf99nhRquvg3PJZw2gQPat9Pyrqq a+1pDzzVETd+LO6Xn1bTUusqFD8oI09q+uvi54mrK2d0A0b6421v4mOhm3Jagv5Ca3nA46aowU06 XyYFjatCbdygJvRetKzrw8O0bNDw9nql7n+blr5qiw150xTn07qyxe20jPCzIuFuWhpXqMuVnLvg Hzl4c766VMt0evM7L64Uufd52sLblazeilr1H3iBC+sNb1jLBrVMT5fqUp425IPYfJSX7NJqvQXb N+ve/Jr2qpOf0DVTvGMnNuKp+rDe4gt45MDkfbK52qr38mp5JRu3PzK8kF5daR9Cj6sxCVfMM+L6 z2lpHai9noK6WCy36uYBAzYF+/HfqSakH3/DDHp5u7m/wU3ghvxu1rKwVuiuhZ3X0xL9lQ1JadIu P4+rH9W7Dflti8db3gvwJCXqfKWu5Plmaitd/MEHV3IG9oon8kL9HVH3xS//IEBjIWAsjgQCixCk wB0HDjiu1QUnevN4eylBhOJaauKewg/F5pzMuOJ2RenE/PcuBnSRHYQyvHzTlxNj4YqlHEbtWMsM hkVQQZVmsGMCO/Rgy7EbRHuM9XVaEk1DsE97vY9f9yXguAT+JfagXeR3he5KjnTB5tGevEh9snmU lVvIjIFUnIss53nb7yt5C8p1hMxAlCk07KSUS1Bzwfo3DK0vVpX6wNC6vhxNLDay/1FdL+WxN6LW 6Wl1Ke6qpGLDbqVgl2vZyQ4lo+NdKZTVHwIG1Sg0yjqZ3t7wG0hHcmwthyQ9RtKjU8Z1gvZx9SZv VefCFyjw/jZx0pKYQJiNaUGN2G+rhGx47Sl1VTv4YV+9aOmXk9WnJRFNKC7Jsi3ejDtLuB+fDHu8 ALviIpMhUnZdqLebzfZJV7KRvy0JzIYqysJ9gxVRVNguRKf98zlDDbXCnWqLP3NmABypAF1sq7U8 3e5tixHw+aucNjkXHwuhaCSipvj0KLybrpgfnsDh+gQ2ORwa0gdOhYKz4pF6mLkbJne8PmgD5tBC ZfHdULwz1sQ3/V70omUvQGuErjTCOHBjU6GAaqWjPP5JJeWPW9Gw+j+7vcVjzS6o7UYdN6Ii3XQe Wp2uTCdOPLCA1eb7rhedsraUmvvLAiCB6aVqYHTROJxodaMmpoajRrkANGjUHckmggx8qG4num2r gCLgTCIkGne3uAllMKFcU8uqx7nINRrPoAxKUTZpN9wTLINJlGucoAY5gnY+37LcVDAMoVzT+ehp HaxHlh2dD7FyjmSAENwJAbex7CLF1o5ki25l+3VlXKbPt/gz2PMRsRn88SH5x/6CzP5JPN4LHBwu iC6HA+ToMrh8EHMMpm8SOow1WJftkgq40EDsEwXgijjk8XZydTQxaB9eWdxxRyJ6b+l0qwkKy2k2 LZ+2DbtqIiQYxMiJNBA4BmoFeBPZc5wiWebIQG7ImWgQUZQDiYwLiOSbaSLqQXVUF6ZpaB3M1SwH As7CVUzONh4fwHPOI8oYurVV7XJZ47Fhv2m5LpI+03BdJHsmID6DP8aLf+Iv3Ersn4SDHZpFC2LI 0QC5NRlacJzdZzANV0WC2kgRpUyYKMuSJclynkPKqq0jWjcNOXcHcoOKMEYCD2WLcsO5sjUFbxop alt7Og8xyjqEAaLmKrM1NR+GLNspaShzocAMSBKH3gYMhgAi0aEWVMaJaKHhyJQOQzAId5OFjq7W qSjRFqZzJFvJY9qvuUOSPuQDN5hDOsicAeoymashJN8oEuS5mMUZPNdIwiGEASPkFZNBCJpzhMEN bfIM1AxSnyHD3TLOICVVAyPTB6OtiYK8QbjvSARVHktJ/GhQDBXnyqCzHuq6TT7T4VaWa+WhjrJw vRUqRTQciTYlLpCYcAXP8WyfJ21Ib0zsgOumpwesXXSD0xap9DwUvA8igy1ojyYXtTRz2l1LEbAy GFjZb7Gls3ZBX2Beb3JftRPfOBKdWpfjHERCAURvEkJaqi2hp4UVEro4SLkMfN1WvCyp0SL0aeM2 9dgSBigeooJEegoX3eFUeS5l8IeVe2IFrEJS7tAIecQi+YAe0WFHhIMOsaeOCImqlArMEV+hzD2M PM0yU4QlvkN1HDnSviPjhLG1XNBw4XDBwi2BrdNKvVsufw4kCS7plr2GazCpklISU0SJmStYBG3m KsrcSxyKiXIVSKgoCzIEBcrcxowU1VjsgcSaYiQYZjTP21MadFqXNFlBJs8id2qgLvYeqeaORNjp 4U6nVGiYJbBofEMCcCw8i3HtWz6axhdPvOBhF48nMAigrpDGJ+8QCw8myLr2NCfhOo8fEEzk/Tz+ QKyADerjeQOwwHWfhjVHIIJvMlA4T+4FUQ8imgOr1Hm9bJJ63l7LcCXaXBTvxZpL44t446Sdkrcu TUMSjXMJDY4W5CZHw8mlnNByaXoSNF0axhhscIdnOUkEeEHaU560WM/TyNOSGzEvihnzGjdiXuPG zGvciHmNy5nXjpnXUukO1GtH1GvR/MC8lkbTgXnNE+Y1Y+Y1T5jXjJnXjJnXPGFeM2Ze84R5xZee ednVnnjtmHglzEEeMS8hlJg3oZeYN6GbmDeBL8zbp0aLsIt5cfg2A/HS7G2GjqfZ2wyMQLP3QBg4 e2d0gqN3kzEvDtuym+mormV6ErqqE90JnSGtu4HuUF9GvJpupZ4sdSvfL8Kl6GudEa9u5full2Xc SvtjGvVEX2ySPjYX0w0n3sR0A7K3+BlksnuEPpOGYAeRsECxzS4pPC1UTUhGKZcEdJRhLyUi8tzb 54nn3jyJlNW3i8n8JxyTFlcT4NMWTNbwDw7XWqtIujxMVLWrrVrcTWpahokKiruu4Rg8qcXnycdC TUsNLhdKqdn018XP8L6EmaJto1q8H693yoowK8tyNizA3yHCsTa7Vo61I8OLo9zcse7KUoTuZKE7 eT49hagPs6fU6emgzqr5EJ/Rdld8ald8YPFgg7H3cloXqovz+Ayms/H5/hmMnp2JdHZ2mAOnp91z Iao95tR8bLuXdA5FzEOkhfBMePvsHUE1iGARKXXUJ7uEbLuU7ZL+hjLwXblrpZztqKAvRHt6moE7 z5b2FjYt7FbdPYf57HnMuwNLrGv2rHTPJaJLgp0NuM1UHvzBTuxb6XZl4dh0eWoTBXTzvI27A3u6 C8/HvzsJ3SjHffyYnqGiZnG/E+FFlbA7CfsqAdwT4WRhB94b1/iTVgjdC5KwvxXG8R+QhK/phP1O DDrMIZXwYfn6TjjEie/SCXtNz/ZkefZ605wE0zSvif/YfZv4vy4JhwrfKAnfwfSBnXCs5Vl/Nyf2 JCFr/VEF7unv745ET4PfOh2ZgFPoS4ozucRzyjf1Cj6V5s/W6Cybcr6F+ZzuXzIuwpUjz+2h9PhF P4Ybr8luvGPtX5Cd74mNag+gjxSEfkFxzA4rDv2SxjlLjhz6rZAb/nDe+fG2fjjuzl6QjX3fEPAE nxEZtGbkRv5R2Q/fSIXzTAF8UD2TjeyTon36SQF/3YkIC63zCasbDVW6zr48jgbOgLHz6AX52Pt9 gTWWI7E7ISMkFEU/qDubv4q+Xt0Tr79bv7o59lvf2RxD92ZadJ2RRHmY+uP4P9arZceSo4ju+ytq aUAuMiMjX+zMCAQIEFL3DrFAZoyw5mLEYFlIfDxx4kTcWyONZ2zwotV1buQj3nHyQ8uuTeJ9oUiz f1X/c52qj/5Z5bv5+MPg0T/Xe2fsxRvPv/11gD8c398bHwYf88ZHs0P+17n67dmh3yM5///r3r37 o13ih+Nc74KffMsb4vsE5c5Eyw/rld/P1KKdo7b+QS1++be/xvfX/3x9yM9S8Nnx9s+3AP948/r4 7OsA//rq71/dvso9b4/nf79NyeubX/yLl6efvnrbj1fPRz2K/T2/eqrHb+zjy6Oea+jxzVHL8bvj j38qx1+eWqtnWUed+9R13AyXc4+jrgX85o73wrI3vl4OKeusI2AzXNc5JfBYh8g+7SZgwUJRO0UC m0C6nJ372yFDT+Vic9khc6RMcZVpEls7jmpm7VqB7agm4+Rqk7V9cumA9q2bwQFNu2b3SGKzqa39 EGqV1HicooeKnkXjmjkOtX+phf2u2lOLhrO0j/SPQKCjn+vhH509TjPH4LTV4CbgeS47blcaId2X b19FLEcvJYJhStlHLzV3qwE5eXI7O9Y2B6YFviMqUqFkL4rTHTugX+vGRy8d+4EXL3EF6qBwxEnV ggA86Q0LRlkOqVAt+OiWHvS0CXz7Cufy0l42TgGuXL/dfNmTem78A/ZYdzvVE0TWxgfwcqhucq1M RrEkhkcM++rZ3BCD7kwZk2JxULhX8Jvh3k5C97RYfH0pzZZGxxtevlpCkTseJ8XU2+JkGj2wudTt aO41MafCiXeItAdqhAWHAnsZoNaaXHHHB7D7XCzKhes9noJsMah0SjWf+t3qTqm70xJlROpmBGt3 wPBZkJvvXR5HYHdDXaH4OAk99wE7l1f3woybp2cx8CSeNGzR5dUKvRBvyhXXdstHN6xOT2IpVHxW j56lMnUb26VCVaC2VQAvGkxai4JHpw7ajE6RGGbIDEWGOwOYigx3dZed53lutKjCOjysnZ2TGJpZ 5XfqgsWNGV5H9bNblCIw8q5FKQIjVVo0iDqQ2529jRCqWFMKq4urMkLTvqnKjAh0b+O9RXsGdtVW WNKZiNYnW2J1GMd5Hffs1rV7FSjztHa3qWumTmeiWqlwt/qM6Dpit3oz65rxVyGO0VK9WwMySm1w +w63NuHx7OkVI+WChqNMHWkBiUogGlmZd3c96l0vOqmygDTTuDLT7nZZO0IMtEdIix8MP7je1uMQ UY36fH7i3H37eY6surysbj4NrG1YssbAk+nCdplvsfjN0xc/fvq5zfKXF9twvHzxZF7V2uzocuCz 1QOdG7PbqlLV+v7L7enTcpYi+3j5/OkTKT96+fKpnLNYyNEOrHOAjXxSBwSfoi02G6DWJefclHSX rNNSQOwi+634WZs7LIA2CA9Mmr64AwLjHOXONc5izvnmuDOHiVFBYmFRqOzRb+54oVlTbAWClqIp hjP6g5YAzhzShDv96tCGaJAQr1S0Ngv47YF7MomCAFZOm1tia5whNAXFxmpJxRzrKVexs4SLOCde YI6shzwHC3AFYfLRdXvgO+kJ7ITK5camStABB+iKN2cSC0wrmtwdz6twv0M7hC3rdsVBJJyvieWC 5HrADqO43D6kjZCB0lnPCTLhBE3YU25XPFNurhCtwS/YZkVbeMgwvK8xdEDosHzm3T4lJAgQ+JBk 2Td2fOmFOSTOKqXXPElgLnDsLq559z50c6YjJKPBhDDXwASqG8IYAbtPqjPCB0zRzWnPvqwkf3FK kSxoXc4lmQJmcEqnFakGaRuwO4CZ+KDM5EzAJEVGFjuXwyhwKKXRpC4Y+JpOuDmncuiySgcURB+y wqMKQwVcxwWvTTs5koX1d4Wdq2UFbnLFHlJg9wNw0at8nOtd2Mfl9JGnEXbkfahOPOVdrDyN5G95 egEvnt7O9XAa+TghhMLDW9otGbHYXBmx7hECdMNG3lVp2IwQrMIQbPYj8FTkx6i8zSBuG1GMQWNl YKZhtc9sGT1On5jZILMrpAjR2EFcDePusYOZTh/p4s0EAC6dSWsNQ7EZbx3xXo0HWOHZTjP8Ci5n 4q7C0gSGj5cEc53eFEHL2wg5qgTziWJ/zXXK/AGFDKNRTnhkS2Ti9NeIbCXTTzhgFcVYvSIe0xtV K16GtwdupBJ37BOccjwly8yHQ+B9XsU1+ojw9YbHTl7usEcBJp5RYYl3pGJgqZxWd9wyCoHdI4/r ZQahT7w5rtKaJhfTmkZRJR5nijHiF6fVA95vNrc2jZJ7fvwibM4RF5v6mXyBNdPNs7KBO8kjrA1M bEXMWy9npJ/nQ7Mqi8M8X1rXM9OpYXmQW2DAHTI7o42ameqZ0EbLVJ34aFYk8sjkNmZmqid6Gzsz 1QuhzWyKrJI2WybEHfdcb7Fos2f2epW1OR8l17AnICIw79VOvEo6HfXb/K1EBIejHWmshoOthiK5 nLq31TPVPefbWqQnFxya76NZUZXsJHC4VVXkvXeWZlUlKTf72x4ciMB2116Z94BaSqS9D3QjhunD O+652kxQI0rZ5ByOrILAK6uAmK/dh9yI0lqX62zqbnkoU2cG3FXXuk59WKJ1Z6tyS1VqlsUdx3L7 bmfGY0DUs2vhSJWR93r41KpRH5mgIEgamRO4Z+aYQFvNAvFE1Za9AzmtTdPDXhHGqc/2KFdtM1VB ZWi7F5Py7J2xbm60lmwMgt2oXZcKlgFGANzTqhrBHs4bVHvk+HCSB8z1w8eX6ojTx+B5K0pwODED pjZD3Rb1eh2YpPYdOT985msvcXd35gDMLO8+YoDpxe4jCJgNvfuE0p7lbx9rOWZ4QRouYmUuPTCG 5eM0mvi47WNiDOLQ9eZQ9KI7iC3lbmoLt+4oaPTeiycYW2A/m5EHZINujUHYLnR6Bg9zKOId45AB E3/+AbOaZWZA2BqkG5jnx2WCCAPSQBEGcoaBRpuXQ+Zo9Y4E7N6q45Im30Gs7i3NSV4bs3KEf6z+ u1xxYY6PmCHFXxPfXY6H2rrcZxxg3DHkSh+nfoWJG9qXwt3pisI8Tlw3hZ43eE/OS4HUPTI+Hq+6 mcReIBVM554GdYfLI0vq9kKJFLw5vpRHXd6iOpvZs2HvKl04zeryktbOBleXt1DA2B0JrOy0dUUC j1heWIuTWVfnZu0FaahzsXY3l08m9Cgcd8DYbpO6Us42MeK5Uq2JIdvYLbDeSbXa5N5c788gBb/l 9ZXrd3hxsigwuin3x4lidFPuRTLjJVtBhA3GSxYQMZkR7jueNGYsz6YZ5VihheFV2eOA7XA4MKTI Dn9KQOgjQ1fPqy/i23vE/r7RNVM1n8K6gm0DQ7UVnKUOf+HoDs4CDF23xO0+v3QHZTFsIPhKAnrY XI/+xofiO3gEBAr6Ami291JC2nBKLzVu9YdTL0FfgBvEXOuNpZdoOhcsK+SA8VQJWIO8AJqjeg3y AmwfwLHcH2G9apJX/IIN/+27CnajiGHofb7Cx13QtEkcT2YqcUHQA4ce0NwQh7KioqioSF2pv4/f c1IVDuwhmzdJHPvFdpxezQBC89zG4THBW17HATCDW0njALizleG5RsWsxKMQEPqU2n3DC1OAUMYY 5FYGx4YItbL0rY31pKGkJ6m2hOjh1IYABmwxHWWAae6nZ3wAAHfhldK0jNW80k21A1ihIx6M979p HcLKRUCSjIvUkfWUZXiSAnbBLBmAWRLkylRgurDEy57ZQKj2XAtMPVo/wcpUAByJxy9WwLXzXZkJ gEM4rz7ANVYz0E237u/KQLA6/EMZOMBhmDKwgIMlDVesmZVX1vCGmjvHhaWi1dKPs7SYXnpUFFrx CpMj4PD0QpcHjkxSWLha7W/OXIK72nOFQ1069FF3wpgcsY1bMkYjqWUU0R1imDV2n47hoOZFGFPg C0xrbDU0TUusLlF0Atc6LAdm/IOZOBcE8+AVcZUkSZan04RXZhFcAKy6VJmDmTQhCC/WhvGoK/6a /TDdvZne75PnwJpVIBJdzQIvYVw5cTWp7L+mQz7uPydf50zObrvy+4fpsOG7f0jLssmMTGcrBmb3 iVQ22U++duEk51OrzAWhkhpX5/Z6xEOzpcKBwv0u993Vlf1u2nCkUJGd2hjxmZVKKJg46owkbilY Prt/bl7+y5zif+jlRvgk9lz68/TlcJPl/ChHN+1w067k+HX/NF1e982ZLCGencaz89Q9tqZIpUQI O/y+Pf+Q5/uHB/n2/UrERc/yeUd7o+xWtsa24fPC7opuo+bJSb7IWoNjCjw9Pp3l/skFjl+Wt6O7 sruwffW5sn0nJZHN6xz2VNgCwfLv73+kh91+bad1UP7C9Md9+gPO7QiMCmVuZHN0cmVhbQ1lbmRv YmoNNCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTIgMCBSIA0vUmVzb3VyY2VzIDUg MCBSIA0vQ29udGVudHMgNiAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94 IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgDS9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgNyAwIFIgL0YyIDggMCBSIC9UVDIgMTgg MCBSIC9UVDQgOSAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAzNiAwIFIgPj4gDS9Db2xvclNw YWNlIDw8IC9DczUgMTkgMCBSID4+IA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgL0xlbmd0aCA1NTUw IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJzFdbb1s3En4/v4KPdgRRvF/61qbt boKtsaj1FgdGNpsELaxNsW5QLKAfv3PjOVR8IkuK4wQBHH4iOfzmm+EMzw/rYbVeO2XV+u1QdU3K wD8a5KQj/K1Z+2S8Wm+G1dPbqF7f0hKjbl8Pq79dWvXudjBq/Rr//DWcqfP17zBcwm6XIpj9cVga bYyNtAZGpuDCF2d/vHr35nxprU5n3ykvI3X+cv18CEYHZzMcMm6v4xEvzmxeni/B/pm1MnCw3Z0Z oEn7f1oPVhkNzugMngBTq35Tg4MjqlOpGLUhUGCMf28IGYQediE02gWAUVvCptDipAOtNigK4IwS IY464XzRjue9zolwCoQtKoo4OsIG7eL+ithWWEjQFIKZp6MujCNvDzoEwcTO4SmIAx9ndAkdzlWb fn3O+N9kL0em387LYeKSHVNrVDN5MLkCOPSuAva9FICz66QCe95NSmavQ6dzDrJawgDZEwQiKqxL F7+b4e2TwYEVsl3wyA1hS/McRDgzsUxkDCjFRCFmT/IYYw5aKhzEJJ6kzNYkKpDOmiE7kjzuQ8zQ UgiTOBIrU5UQusgRDngEwqwDUbG8OjE1K/kE2FH8OH0E5mabV4NIJkzGQEPmHXcDKEyyZVGYJ/ie U+cFatE5mY3kvWgAmBNXNAJjTFw0hMNcJzHEgZdLBHKUaY4PEGdRduJHIfWR0itUj75tCIPTATKa goYYDgw1MX8fiWmApKWo+FDwDoQq0vmQ0bEIWZx5PuIgQhYHnve6ECThfbBIrcPgH0FKAe/pAqM1 ct97yg08jSLhPVLJJLT3kZlFzVuDxpWhG7No40IJARnBytEdUDLHQwgETKsw8kPIfJh+gDSLbvQO YZh8R8jasTa4m65y064kcV60hcMpXE37UkW7FhvLZWU3dhROC42FOoV1Ds/KzuLZG8KwKDvPobeO FM9OuFiHdzi7LBXMVt5eOMetpbuQnVCxlu5C9qatD6gIYtLUWio/HaaExv0EDXmO5rmAQtGi6SwF 1iTa7hJFzBpimZ3IjNjhdsdJNmIj5V3WQxObbFmpI+0s24q9cAEPuDgLVeuFm7gC2PWuWqklTQrA rKRIBctcp6SVqidCw6bUhcEWzrcWJlv5+u2GkUMM6QDEkqPetyEMdxqVxg2lwphHBU0l78UvSDPc h3eBiHAdTj7KUYUcSD5JhkBxTIxZVKiOhTFNc5NAyMdRC0FrrEKmAoKnsdtQemi3E1WzZ3ZWHMfK BfOQIKxywy1qsh7yNYXOnpPm0s5z3HuEDcjmOq7ONOPsiq1NCnYVcO6lcKbTyUlFazo6fsg0mV1L BwyAC01Dio2TZ8xu6KSlGuLNSbQhDMckSKKxaWIJt601pUrPA/EM+wVZdG2a/ZZXVQp0fGgdVDRt TTEZ1jC0LlhZpiANONJNGV3DPkjztnW6wPuNPE0AIzdbWtPFagiudOPYTMtSL21QTFlpmnKSNVPH RSZwVWvP1PRu8L2e3DSZnyEsgsmtAZNCYIk5i4BGClvT15rWMkV/J/MtPmFqyFP8OKSVy3SgbNsQ hrNCcOJMtQCkurhKLgZoFQQhm2hve9ZwIwrQOYgNt44Q2ru20OVGzGwL1QnE7GymOoKYnxeZMg/N cUbANaH51LyJvL9lCN4qR9RLwwn3S39u2FcJo6yHLsrqij0fmz0+D6tC6PhAjbI9Xy/PG3HHS1aI tyNkMQCylKIVbOZ0Fi3BeOql9vK0oThA+WIlJUhe3jW7QZSnErH0/CDFpxK9+HyprR1To/BVuhC2 Z2ieHp4d3O65vXto17U9nRBKPfYBC6uH5wu/FSKN+REG2eIIyiMEuBL0/EapSBUN8SPEk6h4Tnsz 4ax0EO/puY2sq2AAZXoK+fYeH1dKeRBDRXKhHQMx4peg0CiimLDMkhriQy78OkP3xjE5DqiXJded Byeazb2qQINfaKI65IbMS1T4Qu0GjeL4w3pY/YwPpfXbAY6CtIEnk1H46WiiwlZA7xRT4Ot2vRkM zcKTagnpY5xavx5enCmlzpdQvOqZWpy/XD+HVUuoyKbAlh9357dt5BfLpQyXi3FanTAahxdWRm5u 4TgbiOL6CRG7kB/tdmSz/XU9/nh11bbbz2E2jq6uphN9+3HVE7qrlJpTCgw9CKEChmS4Lav24xRE W6HQfxzExV6TajJ5fX3dRsdTU2pUf3tuRKVPZ9Z9xlb7iCrVsqMXu8zotRinlwsZpdn43cPnyZSY fpx9Mtpup0zJGLYTs2WXrDJax+3d2WVP9gSSUwS6SK7uLtzJ0Bk7M6LNn7e9J/PUYj/fu0HenpJ4 4+a8f/P2vpxsMVF+ToIZJT+P7j2bt3M5cOGmxJmyafxxNVP4tvcVw70k0wkkOyXvSaaZ2XIoyfRo eTpV+VFxv//+7r/8aXso3ZNq5/EX+QGqwLG1aibV3PF5+uzVUXf/AUg++o0/Ik7zneSLkNxzmQ7W tL2tArwXvrysD3CfDh89ehZ8uyQvrP26JA9I1cUnqnibfnS6h+fp9gRNH4ruTKzd4cm79V+becLC 4+Y/6PpRq6EnZcRDUO5f7Ksj6m9z9Nd1PVCaByY+fRDl7oPoolWEeETGf1NBUPWIPH+Q+jfn7KF5 bg8me70dPxw/h2xH7Nm/2m9x3+br60b2+oj8vvsBqa6u5la2ECxmXkZujrefeVYtug+p2ZMPz+Yn 4/CiTj/eOXEaTRfJ2u7TY5ye+8yw5u5sd3DqDr4vP8C3FqcxQVYHXpblzNdVlyBzQncGZ08+4vI9 SHs8pWqe9E7+crXifrp9rfgoiRdzobHmbkmGyng87fYdUA74Dthblae02P69CbntL9PUD9u0OyVB Ts+p6RqX7gXdyXv5Dxk9++dMxztJ3tPZ3tH22Gx2D5HNp4xaoMO39aQ+rGZ8srA9zmfK7GimSnft Z3HE16D5WuK2MpNbTnidrKl7c+JnGf727oOM/vumTbvv2uh7dSujV5s/ZHQzrvv+w5/vZfif9xsZ vf/QtqjL/8no9s83MtoQxZ/Ww+rpbVRPL5WBf1ZdPh2seg6D35XVJRX1FxRh9Yt68dKofw/eG12T 8i5omNoQDkV5DzioG8LWKR8EKB+djg6Bq7rAygQbguAMllLG/yacg3ZtHkz6QgYZI4y6zVpYXY3m yYJ8fA0yW7RBWAhktBiMJZBwXzBe+KIjAKPmpQ7+DyajTwgNcg+GjAO2GV0IpopLlrwOoA8Cq80I TNIl0Ep2zjiaNMT6ZnA1NcveETY8n9lZV6oQGWEiLMCN44LhCHhcERzKLibfE/NwJbGhDsed/fEj e5H9yAJSTypqz5gCBrgHAU8YpUTs2KPMm71m/3nWkSlrmmlL8oCkkWkalAPS1jdoEHMuuFx5d2Zj udDREDzWFjCG3HnchDiTz5AJI0ZrkFGyPqGb3om1RAr6JGdFMh6M+AkYmYagnUA8KxT0FnHQFabh EiSBcFJM+CNDZJKsiAQY7kZISbJEMLgbG8boQbKk0FmvkfMTT4csisZg0BgDjYjZ3eZhEG2cHIu2 tMUJWUS4AqnJ4lSE+8yaAwQu0TdHUezoc/OEHI4httUFKcZA6ckYT46jccGjpxUjH2NtnjFOXgAy BVl8vzhV3cPsJLXENkbq/4RXu7JcNw7M5ysmlF2lawIkQTJ17R9osg1VpcClGznY31+gGzhntA62 FGj6gocPoBsPfbtL/Pd2VadYvcufMPeogK6gwdylAHfLCnwy/vacRz72Hex5ej0yfDNd2iTx6rjX 2RGUwPHZPKf8jcxpTZhM1HZcxDxTcDeDlKwxpanNIIF5LMkV6/GduVIH7RLesRAg7BOuD8x3TCy0 yDjYfkp4JTD3G+HNNwg33MvH4O12Pm4oj8/sraMB8ClOCx7N4DpncBWj21xZnTen3hTJLV7Gh6vx qMkAKTJHQAZIXS1wC98lm+8YebbA64HpB2n0y8jLNN7tgnm39LJ7X+/NxIMFp02A615wkbeovJh9 cK2EKwJCErIPD8ZapxOOyRwjG0r21oB8F0+Afo5omZEIzesLvC3BWYfGN8mCbEyyLokTL45yz3A1 VGbuOB6+xMHKrV01wSPXNb81VAjrdIAYCoT1k68wRMUGs2FAV4ONVEvgOHnMyxz3HqvMqAI2dppH SMFmTw86h+OwOamQwHG3aVRuYN9tZjIVUyjGUiGB4zSraFmAzOpi5LeriB52HNHy51/28OGqCFiU GFtKFxpSrq1eW0efYWvkyRMitlUBmRDPyuIWMC62djpxIiPZzqIR2L/2DDQKhlt2dkoyUaDMS+Qq 7LvtQSfOyc1WfT2xWWYZoTMD811zcLNTZw9slllIJg6xk8UycAT0tDxMEcAj9VCBBo4mMR13YvoF lScg/TSQz+30JNtA/2Nn5GWdGJOY2ztxDjEvH1mIeNNu3G/m8Y4bMQnlPBzE9BxA6nMwQZ6VZ3dq +xRBOjKnncxw0sllx9yrK+92uB0FFJBP04jpai13V1TXwIypokgE5mmuVf9uoSkVQUPpIGMkePYb xrMCIxmL57g3+O3Bzv3v77UyHuVh+3xIi8DEG64PNU6dbCh+Xf7z8eP3x58+D7xew7d7/XhE0vKF sb3/XNP7fokAd6eqeQ/9fH362a/vjy/y2+uvx1dPBs2e3vM2J4WPPF8s/3x8BHIPeHEd8fev7qU2 Dr9UrPFW7xzf0fW3Nz72NeLPx5qONRE5e7qW2rZ/bIOjfJqRa4r5aD2ml3tmQQrkzBKPiIECbX3i jkpMu4e8904vBfbPO0j1ecGaW2oCio79HoicbafM7vsYiD5vYGTJhSO93+aZeeLC4ZR3+/gYv9jR ud1nez7hfJLY2q/DmmWnlC8xqOt6mGUBKzcYGonbLd7GyLs92hx7c2s0nW9eXeDy5xWFxUaqIJPg bfakZ+/mGXoJs2Ci86zHUaxHretMY58FozEraw/c4yk0+yn9ZHG4MLROO8agVnG5sFhijE1aDEo8 qKvAnKpmmTeGm1nWaNOj2MPKWVCUSe8NJ6EUM4SMJBTWDTFm7MCx+qTNf6vUtVFBctL5vPEsPinm VV3FJ+WklF1J4JhvuxSfEvfiU3eA3BFGNFoDvd7Pd5jc6pybDjNR4cHeOWDMbKMXudATjFF7cYiS sq0YotpH7RwzaahipBl4JLGw5WC/G2a0QWPuUjuxtWJWFMRhWsQiHCX2Eb6JkWyXGSPaLmZxhFut 5M4Rjb3/541nMQkTIGarzwudohHnudBEWgGvPITSPkITMHPW3FnAAgdRdiUiwnNxOPqEcaRoRNhL +5xjz5WZEu+iEoQYo2WKP/GVmhKPotKMuM9mpf7EV2rKUbQVmxJrssnXyijqBLDkjdXICgMmLBVa CHq84M1Y6Yjjrq5iTeJTKiTuVz7CzWfvRZvEszSe+EpIiU8Rh3hIqTrxlZISzyJO4v1mnFfsEuvH +7dzlK4T28f71YPx72ar/JNQizeJR1UJesKuhJN4F1Xo2KC8vjl+XVnHN1uzeBJglZAZ5HV+JcmW myRBot2h5G/3H+bNEuDKOQjG3KekHJyeRyokBfctj3l6kQdqmmfeyvb3zLOLP6FNi5KwL+Fau5IO B7imt+6n3WNn5o0ccivL+DD4SxKK+S/ZhFvFADjvDBjz3ypz9K4uglXmGNpCCDT7gHdlIMTVtN8V IEbBSvCA8y4Y0Y9rpaNwlekpWglHRSmNR5G1UERV8Lhzn3f3EZfsVz7iENtP8ko5DIQicBlKz0al IMU4W7NkwM5ZkvFS/DAfIRgv5WwwhT5Q+CZmS7LWcTxtzkwiOjlbrtx9YLdZclW42ixrjEMDqsUY NEvLqpiCrGeuuPEsO+dSqlc5edi4P7/Mn/80xzQQeObDBXJJHPaFAdD1ydMEnWhg0l4mn1JV3lk0 iZl6fQjYgHmcICwubzK7Hcw5jmFuh7vlGNQbh1M7qfa2eLuTOmmTp51kSUMCDczlyK+2stPSQxI4 xmX1MKor56bAOt5xpPOAULyeXp+DFIHbeMfiQFiLfbDAy1aOVbqjpgRE9tGNAASGRnWjTQ68+Dlq VWDEQRdqWWC0MLrQhttSekIXU8Bi0talvKqCYboaH5YtpRoqbWK3G0dbx+CYGgFCroY7BIa0dJ4P fouDJwmxlKVGZzQMCcPc+Y7LLHxH2cdhCMo+GOHVM2Rj8iFZaHWg13mzC1+Sc4F6AsBLOuWgHb3U m51SXJ2pU6PrLBhmqe2xe0foLxhJI5GvVePTyhgtYSAkWXXddSsc5lYPI5kEDWdit4vVyUghKqMe BuWooK+/7e3Uw0i+/2dvzGhrJD9bcn2wdqpLKRLiyjKvrfPpIwnblPcZSVjXlt1QzqHUBsq+uJKI wF5xIcEZkzqWwyyR05uEsIA6odA1WYglSi4gTnIkXA0GiQsLQjNGWPYkA4yO/fY/f4kVg67KFbK9 okXboDAq/bboF9mN2+eoISsJlr2qLBYS/4/mhd9IjsL3GqbQWDq41SElhKyz3ehyIUnfMHP1Fmha VqOZLYYYM/fOyU6MmXp3VkhxTccrN6txwE7I1dN/Z78sXg3wqWUwDVT2xqcRdu60PgrGi/emBMWY umIUwDMdR4COlF2w+5F0943BbDH0dnZ6htuY+s6oh1E5ZwaYLBhn5lUn2XCy/jgGoIO9KY3c5F2W FB6AZKXD8H9UBUC8d7XGFkEmiLWa1NfOF0DcmrV+NWXpkeiPHab8ZCJPrTZyNXqh1Wa6dDbsZcxq MtCtBObFR/RaAaFdGcazFsU1INWAaMJkQGarJQWH4uPNdC1DeJOT4RiNmx1mSOkotoHpwY60Fpjh 6oNXP/myjlYicdg1QrFatkrSEa7Evl7h5duu6PBz/7APvqZUoYNhuLDGxe/7afv1Pdpu4GKXVc7g 88V43Z3JRZA3yln+wbM95fn3d6zERSflFsHZiCDVKEiIS4Refl/98/Hj98efr0cQxn3X/J//XPMZ 7dB49hVxbf35+ny05+v744v89vrr4fxfzp3os/vZz9e/Hl9W/P2rN+rbZ8GnT5dbGixfvYVp4/Dj iVURPz/BvboVH4vV16ef8fzqF+170XTC9Mfrpf7W148HRBTXxI/BpB9dwLquGf/cK7zvEzt7bT3q Ce5r4/91r7iir4xfvvt/Hv/+8t++q2AFYRiG3v2KHDdlbFlcOwYeHczDDtKrh00EB4MJG/j7JunU 4sEe2tcGXkjyWtLWwjJBnGAetVhBfHGnTVqvzvXdEHoFVuWWs+L5+6O+lZOUUtiiR7fc4TmMI/S3 CoC5Ezi7kufWKMSMl6ZLm163/pDETt4uEDWGTNLCEiZNizJfp3mBYWbm90DYfXARYACju8BOOh/A 5z6t0YfIN5QsibTEDfyMf7UofF8gfcy+DCXjS8BXnchqcdGsxQ0CK4z5HrntCo5u8wIrRgB7CmVu ZHN0cmVhbQ1lbmRvYmoNNyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSAN L0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvQ291cmllciANPj4gDWVuZG9i ag04IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgL1dp bkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9Db3VyaWVyLUJvbGQgDT4+IA1lbmRvYmoNOSAwIG9i ag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciA0OCANL0xh c3RDaGFyIDU3IA0vV2lkdGhzIFsgNTU2IDU1NiA1NTYgNTU2IDAgNTU2IDU1NiA1NTYgMCA1NTYg XSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvQXJpYWwsQm9sZCANL0Zv bnREZXNjcmlwdG9yIDEwIDAgUiANPj4gDWVuZG9iag0xMCAwIG9iag08PCANL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxh Z3MgMzIgDS9Gb250QkJveCBbIC02MjggLTM3NiAyMDM0IDEwMTAgXSANL0ZvbnROYW1lIC9Bcmlh bCxCb2xkIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDEzMyANPj4gDWVuZG9iag0xMSAwIG9iag08 PCANL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciA0LjA1IGZvciBXaW5kb3dzKQ0vQ3JlYXRv ciAoTWljcm9zb2Z0IFdvcmQgOS4wKQ0vTW9kRGF0ZSAoRDoyMDAzMTExNzIyMTcxNCswMScwMCcp DS9BdXRob3IgKGJvb3QpDS9UaXRsZSAoTm9ybWFsLmRvdCkNL0NyZWF0aW9uRGF0ZSAoRDoyMDAz MTExNzIyMTcxMSkNPj4gDWVuZG9iag0xMiAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBb IDE1IDAgUiAxIDAgUiA0IDAgUiBdIA0vQ291bnQgMyANPj4gDWVuZG9iag14cmVmDTAgMTMgDTAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwOTI4OSAwMDAwMCBuDQowMDAwMDA5NDQwIDAwMDAwIG4N CjAwMDAwMDk2MDUgMDAwMDAgbg0KMDAwMDAxNTczNSAwMDAwMCBuDQowMDAwMDE1ODg2IDAwMDAw IG4NCjAwMDAwMTYwNTEgMDAwMDAgbg0KMDAwMDAyMTY3NSAwMDAwMCBuDQowMDAwMDIxNzc2IDAw MDAwIG4NCjAwMDAwMjE4ODIgMDAwMDAgbg0KMDAwMDAyMjA5MSAwMDAwMCBuDQowMDAwMDIyMjc3 IDAwMDAwIG4NCjAwMDAwMjI0ODEgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAxMw0vSURbPDhk NjFmNWQ0ZjcwMzRjZTY1YTUzMGM1MTY1ODFiYTFkPjw4ZDYxZjVkNGY3MDM0Y2U2NWE1MzBjNTE2 NTgxYmExZD5dDT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN --Boundary_(ID_Eaz4PIFJ+OMlLifwSTArLA)-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 18 10:48:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26626 for ; Tue, 18 Nov 2003 10:48:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C4C626@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 10:48:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61024579 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 10:48:50 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 10:48:50 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E391E6F4AE5 for ; Tue, 18 Nov 2003 07:48:48 -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 14497-10 for ; Tue, 18 Nov 2003 07:48:48 -0800 (PST) Received: from redback.com (unknown [155.53.6.19]) by prattle.redback.com (Postfix) with ESMTP id BE98E6F4AE1 for ; Tue, 18 Nov 2003 07:48:47 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <003a01c3ad56$58bf2360$0201a8c0@SIEM> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: <3FBA3F59.5020207@redback.com> Date: Tue, 18 Nov 2003 10:48:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF - IP Multicast interaction problem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <003a01c3ad56$58bf2360$0201a8c0@SIEM> Precedence: list Content-Transfer-Encoding: quoted-printable Dear Mr Boot, If I undertstand your E-mail, you are requesting that OSPF somehow=20 guarentee symmetric routing and take some action in the face of asymmetric costs. I (speaking as a WG=20 member) do not think this is a problem that we should try and solve. In fact, Isuspect that if we=20 looked hard enough there would be IETF documents support not try to solve this problem in OSPF. Thanks, Acee C.C.Boot wrote: > From: Teco Boot > > To: John Moy; IETF OSPF working group > > CC: All interested specialists on OSPF and IP Multicast protocol > > Subject: OSPF =96 IP Multicast interaction problem > > Date: 17 November 2003 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Dear mister Moy, IETF OSPF working group members > > I want to inform you about an OSPF =96 IP Multicast interaction problem= .=20 > We did have some problems during our =93Proof of Concept=94 testing thi= s=20 > week, caused by RPF (reverse path forwarding) checks, performed by PIM=20 > and / or multicast packet forwarding code. > > -------- > > Problem description: > > The RPF problem was caused by settings on some of the router links,=20 > the OSPF metrics were configured highly, as the config was left from a=20 > previous test. The configuration was absolutely valid for OSPF and was=20 > preferred for the previous setup. As soon as we saw this=20 > configuration, we adjusted it and our problem disappeared. > > But I was not amused about this problem. I made multiple designs=20 > making use of a permitted technique in OSPF: we set the OSPF metric on=20 > values that are related to the interface bandwidth and / or CPU power=20 > of the routing device; metrics on interfaces connected to a certain=20 > transit network could differ. Here some real world examples: > > 1) Token Ring and ATM backbone (old technology but it is a real world=20 > example, I made the design myself). An 4Mbps interface would get a=20 > medium to high metric related to 16Mbps and a high metric related to=20 > high speed LANE ATM interfaces. > > 2) Ethernet VLAN environments (todays technology, so interesting to=20 > mention). It is likely that redundant VLAN backbone segments are=20 > interconnected using layer-3 switches and possibly WAN routers are=20 > connected to multiple backbone segments. The WAN routers should not=20 > handle VLAN backbone traffic, so the OSPF metric on the WAN router=20 > interfaces would get high metrics related to the layer-3 switches. > > 3) On Frame Relay or ATM networks, using partly meshed structures and=20 > unequal access bitrates, a network designer configures the OSPF=20 > metrics with respect to the available bandwidth. This is especially=20 > true if other communication means are in place, e.g. ISDN, satcom or=20 > microwave links. > > -------- > > If transit networks are configured with unequal OSPF metrics,=20 > asymmetric routing is likely to occur. As an example I studied the=20 > network as described in RFC2328, figure 2. I calculated traffic paths=20 > from N1 to N7 and vice versa. I included two drawings below, depicting=20 > asymmetric routing. > > Avoiding asymmetric routing is generally accepted as a design goal and=20 > it is mandatory for every IP multicast capable network. On the other=20 > side I mentioned a few example networks that benefits from unequal=20 > OSPF metric settings on transit network links, which could introduce=20 > asymmetric routing very easily. > > As I kept thinking about this problem, I came to the conclusion that=20 > the IP community running OSPF (or a similar routing protocol) would=20 > benefit from an improvement on asymmetric routing probability=20 > avoidance. An easy to define mechanism could take the average (and=20 > round downwards) of the ingress and egress interface metric on each=20 > transit link. Implementing is harder, as each router in an area must=20 > have an identical path calculation algorithm. So the implementation=20 > must support backwards compatibility, e.g. the new algorithm should be=20 > enabled per area and a router LSA option bit could be used to signal=20 > existence of old style routers. > > Now I can formulate my questions: > > Is the problem described above well known and documented in an RFC or=20 > Internet Draft? > > What is your opinion on this issue? Could it be fixed in OSPF? > > When could the problem be fixed, what is your opinion on this? > > Your response would be very welcome. If you have needs for any more=20 > explanation on this issue, please let me know. > > Regards, > > Teco Boot > > Mail: c.c.boot@planet.nl > > Figures: > > Taken from RFC2328, figure 2, page 18; route from N1 to N7 and vise ver= sa. > > (figure 1) > > N1 to N7: > > path will be: N1 - RT1 - N3 - RT4 - RT5 - RT7 - N6 - RT8 - N7 > > path cost is: 1 + 8 + 6 + 1 + 4 =3D 20 > > (figure 2) > > N7 to N1: > > path will be: N7 - RT8 - N6 - RT10 - Ia/Ib - RT6 - RT3 - N3 - RT1 - N1 > > path cost is: 1 + 5 + 6 + 1 + 3 =3D 16 > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 19 12:15:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27659 for ; Wed, 19 Nov 2003 12:15: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 <21.00C4E33A@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 12:15:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61172448 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 12:15:22 -0500 Received: from 62.241.160.193 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 12:15:22 -0500 Received: from tom3 (1Cust213.tnt1.lnd4.gbr.da.uu.net [62.188.130.213]) by pengo.systems.pipex.net (Postfix) with SMTP id 639454C00567 for ; Wed, 19 Nov 2003 17:15:21 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <002001c3aec0$3f8a7be0$0301a8c0@tom3> Date: Wed, 19 Nov 2003 17:09:19 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Three thoughts, first two editorial. 1) In the abstract, I would like the text to include LSA Header in the reference to options, as OSPF has options in other places 2) Throughout, VPN-IP address should be VPN-IPv4 address as in (mostly) the base VPN documents 3) The dn bit stops OSPF route calculation. What about other OSPF processing? I assume that the LSA will be put in the topological database, aged, flooded etc just as if dn was not set. In which case, or if not, I would like that specifically stated. Tom Petch From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 20 14:00:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18700 for ; Thu, 20 Nov 2003 14:00:00 -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.00C502C0@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 14:00:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61331743 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 14:00:04 -0500 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 14:00:04 -0500 Received: by xmxpita.excite.com (Postfix, from userid 110) id 21FC83E06; Thu, 20 Nov 2003 14:00:02 -0500 (EST) Received: from [64.47.48.10] by xprdmailfe9.nwk.excite.com via HTTP; Thu, 20 Nov 2003 14:00:02 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: <20031120190002.21FC83E06@xmxpita.excite.com> Date: Thu, 20 Nov 2003 14:00:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Comments on mib-update-07 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, Did a full re-review of the MIB and here are my comments: 1. For ospfNbrOptions, should we update the DESCRIPTION clause with the current available options? 2. For ospfAsLsdbAdvertisement, the SYNTAX clause is incorrect. Instead of SIZE(36), it needs to be SIZE(1..65535). 3. For ospfConfigErrorType, instead of moving noError every time we add a new enum, just make noError to be zero. 4. Also for ospfConfigErrorType, in the DESCRIPTION, ospfConfig- Error and ospfConfigVirtError need to have "If" in each. 5. Should we add additional error codes for: a. badLsType -- something other than 1 thru 5 b. subnetMismatch -- for bcast links, or do we want to overload netMaskMismatch? c. xsumError -- when the packet contents do not match the OSPF checksum, also when LSA content does not match LSA checksum d. badLengths -- when the advertised length of the OSPF packet does not match the actual length of the received packet 6. If 5a is adopted, then ospfPacketType needs an additional enum for other(7) or unknown(7). 7. For the NbrStateChange traps, should we add an additional varbind for the event that caused the state change? This aids when debugging a resetting adjacency to know that an sequence # mismatch or a change in the options caused the adjacency to reset. Thanks, Don _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 20 15:11:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22489 for ; Thu, 20 Nov 2003 15:11: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 <1.00C50419@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 15:11:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61341085 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 15:11:31 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 15:11:31 -0500 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAKKBSDM024423; Thu, 20 Nov 2003 15:11:28 -0500 (EST) User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: <200311202011.hAKKBSDM024423@rtp-core-2.cisco.com> Date: Thu, 20 Nov 2003 15:11:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Eric Rosen Subject: Re: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists Comments: To: Tom Petch To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of Wed, 19 Nov 2003 17:09:19 +0000. <002001c3aec0$3f8a7be0$0301a8c0@tom3> Precedence: list > In the abstract, I would like the text to include LSA Header in the reference > to options, as OSPF has options in other places No problem. > Throughout, VPN-IP address should be VPN-IPv4 address as in (mostly) the base > VPN documents I prefer to leave it as is, since there is nothing v4-specific in the procedures. > The dn bit stops OSPF route calculation. What about other OSPF > processing? I assume that the LSA will be put in the topological > database, aged, flooded etc just as if dn was not set. In which case, or > if not, I would like that specifically stated. We will add a statement saying that LSAs with the DN bit set still get put in the topological database, aged, flooded, etc. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 21 07:00:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11040 for ; Fri, 21 Nov 2003 07:00: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 <19.00C5162B@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 7:00:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61443745 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 07:00:24 -0500 Received: from 62.241.160.193 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 07:00:24 -0500 Received: from tom3 (1Cust51.tnt30.lnd3.gbr.da.uu.net [62.188.122.51]) by pengo.systems.pipex.net (Postfix) with SMTP id EB09B4C0052F; Fri, 21 Nov 2003 12:00:22 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <001301c3b026$931b6dc0$0301a8c0@tom3> Date: Fri, 21 Nov 2003 11:55:59 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists Comments: To: erosen@cisco.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Inline > >> Throughout, VPN-IP address should be VPN-IPv4 address as in (mostly) the base >> VPN documents > >I prefer to leave it as is, since there is nothing v4-specific in the >procedures. > I misunderstood, coming to this from [OSPF-VPN] which is - mostly - IPv4 specific. Worth a note at the end of the Abstract such as 'The procedures specified apply equally to IPv4 and IPv6' ? Tom Petch From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Mon Nov 24 10:31:13 2003 Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12579 for ; Mon, 24 Nov 2003 10:31: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 <7.003A1FE8@grape.ease.lsoft.com>; Mon, 24 Nov 2003 10:31:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61794052 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 10:31:24 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 10:31:24 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5818E88EED0 for ; Mon, 24 Nov 2003 07:31: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 22501-02 for ; Mon, 24 Nov 2003 07:31:22 -0800 (PST) Received: from redback.com (unknown [155.53.6.10]) by prattle.redback.com (Postfix) with ESMTP id D44AC88EECE for ; Mon, 24 Nov 2003 07:31:21 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010009050205040008090806" X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FC2243B.80207@redback.com> Date: Mon, 24 Nov 2003 10:31:07 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Meeting Minutes for 58th IETF OSPF WG in Minneapolis To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------010009050205040008090806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thaks to Dimitri Papadimitriou for taking the meeting minutes. If you have comments, please send them to me in a private E-mail. I will send an update to the list before sending the final version to the proceeding. I'd especially encourage those who spoke up at the meeting to review your statements as transcribed in the minutes. Thanks, Acee --------------010009050205040008090806 Content-Type: text/plain; name="OSPF Meeting Minutes.txt" Content-Disposition: inline; filename="OSPF Meeting Minutes.txt" Content-Transfer-Encoding: 7bit Monday November 10 (15:30 - 17:30) ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: o Chairs (5 Mins): Agenda Bashing o Chairs (10 Mins): WG document status - Published "Traffic Engineering (TE) Extensions to OSPF Version 2" as RFC3630 - Approved for publication "OSPF Refresh and Flooding Reduction in Stable Topologies" - draft-pillay-esnault-ospf-flooding-07.txt - To be published "Graceful OSPF Restart" draft-ietf-ospf-hitless-restart-08.txt - IESG Evaluation/Revised I-D needed: . "Detecting Inactive Neighbors over OSPF Demand Circuits" draft-ietf-ospf-dc-06.txt - Awaiting I-D write up . "Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance" - draft-ietf-ospf-scalability-06.txt - WG Last Call . "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs" draft-ietf-ospf-2547-dnbit-01.txt - Soon to become WG documents: . "OSPF version 2 Management Information Base" (update of the RFC1850) - draft-ietf-ospf-mib-update-07.txt . "Authentication/Confidentiality for OSPF version 3" draft-ietf-ospf-ospfv3-auth-03.txt - More discussion needed to get WG status: . "Management Information Base for OSPF version 3" draft-ietf-ospf-ospfv3-mib-07.txt . "Traffic Engineering Extensions to OSPF version 3" draft-ietf-ospf-ospfv3-traffic-01.txt . "Extensions to OSPF for Advertising Optional Router Capabilities" draft-ietf-ospf-cap-01.txt - RFC1264 - requirements for ptotocols and major features . implementation survey ********************************************************************* o Acee Lindem (10 mins): "Graceful OSPF Restart Implementation Report" - draft-ietf-ospf-graceful-impl-report-00.txt Summary: ------- This document provides an implementation report for the Graceful Restart extension to the OSPF protocol per RFC 1264 (stating the requirements for a report on implementation experience). - Five vendors have implemented graceful OSPF and have completed the implementation survey. - Implementation Differences: . Whether or not strict LSA checking was implemented and, if so, whether it was configurable (note: strict LSA checking indicates whether or not a changed LSA will result in termination of the graceful restart by a helping router.) . Whether a received grace LSA would be taken to apply only to the adjacency on which it was received or all adjacencies with the restarting router. . Whether or not additional extensions were implemented to accommodate other features such as protocol redistribution or interaction with MPLS VPNs - Addition to the OSPFv2 MIB: . 5 new objects to the ospfGeneralGroup . 3 new objects to the ospfNbrEntry . 3 new objects to the ospfVirtNbrEntry Discussions: - Acee Lindem: anyone else interested (from the already listed 5 vendors) ? -> yes, 2 additional vendors expressed interest and will be included upon completion of the survey. ********************************************************************* o Rahul Aggarwal (10 Mins): "Support of address families in OSPFv3" draft-mirtorabi-ospfv3-af-alt-00.txt Summary: ------- - Agenda: Motivation, Proposed solution, Design consideration - Motivation: Need to carry multiple AF in OSPFv3 (such as multicast IPv6, unicast or multicast IPv4) in addition to IPv6 unicast - Proposed solution: . Multiple AFs are introduced in OSPFv3 by reserving Instance IDs and using one OSPFv3 instance for exactly one AF. . Each AF establish different adjacency, have different LSDB and compute different SPT. . Hello processing: to avoid blackholing, hello processing is changed in order to only establish adjacency with the routers that have the AF-bit set in their Options field. . Modification of the semantic of some of the Option field bits defined in RFC2740. . Carrying Prefixes in new AF's: each Prefix has a prefix length facilitating the advertisement of prefixes of different lengths in different AF's (no need to define new LSAs). . Virtual Link (VL): virtual link are not currently supported in other AF's than IPv6 unicast AF (as there cannot be a multihop forwarding based on global IPv6 address or such a path may not exist). - AF Design Considerations: . Mmapping an instance to an AF doesn't introduce new mechanisms in the protocol . Minimizes the protocol extensions required and simplifies the implementation. . Presence of a separate LSDB per AF is easier to debug and operate. . Does not change the existing instance, area and interface based configuration model of most OSPF implementations - Request to make it a WG document Discussion: ---------- - Fred Baker: Agree to make it working group document but concern wrt mobile ad hoc networks (MANET) - does not want to have two neighbor relationships and favor keeping a single instance. Also this solution potentially doesn't address MANET concerns and requirements. - Acee Lindem: everybody here is in agreement that in OSPFv3 has to support multiple AF's so we need to address this issue - Fred Baker: In favor of having a single instance (neighbor with a process of transitioning) and doesn't want to see both OSPFv2 and OSPFv3 using AF's (doesn't want to have separate protocols for achieving this capability). This is a solution for allowing mutliple address families in OSPFv3 but this solution doesn't necessarily meet the MANET requirements. However, agrees to make it a working group document. - Hasmit Grover: Not specific to this solution, questions the duplication of information in OSPFv3. - Rahul Aggarwal: Not duplicating anything, it is a matter of having two router LSAs instead of one. - Hasmit Grover: Still need duplication of topology information and it would not be more complicated to have a single instance for doing this. - Acee Lindem: The target was simplication. - Hasmit Grover: Doesn't know how much that problem it is, why OSPFv3 is so different ? - Rahul Aggarwal: not TLV based - Acee Lindem: By comparison, using a single instance for providing this would require more work (than what is proposed here). - Rahul Aggarwal: Request for WG document ? - Acee Lindem: I would like to have some more discussion on the proposed solution, but the requirement is acheived - it seems that no one disagrees that this is a requirement for OSPFv3. - Acee Lindem: Sense the meeting room for WG document status. -> Few people in favor - Acee Lindem: Sense the meeting room for having an integrated solution. -> Few people in favor - Acee Lindem: WG document status and see how the discussion can progress. - Rahul Aggrawal: This is document is good basis to work on this topic. - Acee Lindem: The target for the working group is to come with something simpler. ********************************************************************* o Rahul Aggrawal (10 Mins): "Advertising a Router's Local Addresses in OSPF TE Extension" - draft-raggarwa-ospf-te-node-addr-00.txt Summary: ------- - Agenda: Motivation, Problem Statement, Proposed solution, Conclusion - Motivation: in some cases (for instance in a network carrying VPN and non-VPN traffic it is desirable to setup) CSPF computed MPLS TE LSPs to local addresses of a router that are not advertised in the TE LSAs i.e. loopback and non-TE interface addresses. - Problem: OSPF routers can only use CSPF to compute MPLS TE LSPs to the router ID or the local addresses of TE enabled links, of a remote router. This because: . OSPFv2/v3 TE extensions only advertise the router ID and the local addresses of TE enabled links, of a given router -> other routers cannot populate their TED with other local addresses of the advertising router i.e. loopback and non-TE i/f addresses. . OSPFv2 stub links in the OSPFv2 router LSA OSPFv2 provide stub reachability information but not sufficient to learn all the local addresses of a router (same problem w/ intra-prefix LSAs in OSPFv3) - Proposed solution: . Advertise the local addresses in a new node attribute TLV, in the OSPF TE LSA . Node attribute TLV carries the attributes associated with a router - it contains one or more IPv4/v6 local address sub-TLVs Discussions: ----------- - Acee Lindem: Put the discussion on the mailing list - Acee Lindem (to Rahul): You could poll this information out of the router LSA and set that information from the topology? - Rahul Aggarwal: Will give the details. - Acee Lindem: Ask for comments on the mailing list, this document is a small amount of work since it slightly modifies OSPF-TE ********************************************************************* o Sina Mirtorabi (10 Mins): "OSPF Tunnel Adjacency" draft-mirtorabi-ospf-tunnel-adjacency-00.txt Summary: ------- - What it is a Tunnel Adjacency (TA): Proposal to solve the intra- area/inter-area path preference, generalization of virtual links, it can force OSPF to take the desire path and it has the on- demand partition capapbility - What does TA resolve: intra/inter-area path preferecne, in hub and spoke topology, it saves the cost of adding a new interface, between ABRs, it helps in repairing by avoiding segmented areas - How a TA is established: configured as for VL's, and then it is announced - How data packet is fowarded: . if ABR-ABR link is direct link -> sent w/o encaps . if ABR-ABR link is mutli-hop -> encapsulation needed (doesn't need configuration) - TA Configuration/Parameters: . TA is configured between two ABRs attached to the same OSPF area. . Parameters: Tunnel-adjacency Transit Area (TTA) and as for VL's, a TA is identified by Router ID of the other endpoint and its Area ID - TA resolves the VL limitations: . a TA link can belong to any area, . summarization is not affected . TA can't go through stub/nssa area - TA has added value features: . TA cost is configurabken . Provides on-demand partition repaitr . Mutliple TA through a given path Discussions: ----------- - Padma Pillay-Esnault: Don't see what this adds wrt to tunneling between two ABR's. - Sina Mirtorabi: 3 differences, config overhead (IP address), rely on IP address (reachability is done in given area, while tunnel doesn't guide the reachability), and provides automatic partition repair. - Alex Zinin: RFC 2328 limits the configuration of the VLs so that they can only transit through non-backbone areas and always belong to the backbone. Among other things this prevents "recursive" VLs, i.e., VLs relying on other VLs. The draft relaxes this and suggests that the TA can belong to any area and can transit any area. This opens up a possibility for TA1 that belongs to area A1 to transit area A2 that has TA2. This means that it could be possible for packets to be encapsulated more than once. It seems it could also be possible to have recursive TA resolution, e.g. in the case above, TA2 transiting area A1. - Padma Pillay-Esnault: You're making people trying to avoid VL, while topological changes are going to generate re-routing. - Sina Mirtorabi: VL issue is that it was recommended to "not use VL". - Padma Pillay-Esnault: Any trigger in its own area is going to generate path re-computation. - Acee Lindem: But any intra-area topological change is going to generate path re-computation in one way or another. - Padma Pillay-Esnault: But here you may trigger several SPFs and thus end up with several levels of SPF, - Acee Lindem: Yes, changes can trigger other changes during re- computation - Acee Lindem: Express concerns about the requirements, today we have a limitation on an interface belonging to a single area. This requirement can be satisfied by considering the area ID but do we want to go further and have an automated tunneling ? - Sina Mirtorabi: Main reason is to have a solution that avoids direct links, otherwise Pat Murphy approach was there to solve this issue. - Acee Lindem: But that draft was too complicated. -> Take this to the list? ********************************************************************* o Kiretti Kompella (10 Mins): "OSPFv2 Traffic Engineering Extensions for Multi-access Networks" draft-kompella-ospf-multiaccess-te-00.txt Summary: ------- - Traffic Engineering extensions for OSPFv2 for dealing with multi- access networks since the bandwidth attributes in the OSPFv2 TE do not accurately model the available bandwidth across a multi- access network. - LAN being modelized as a star (modelisation X=DR being one of the router attached to the LAN) but X doesn't generate a TE LSA thus the bandwidth availability (i.e. Unreserved Bandwidth) is not available in the reverse direction (e.g. X->D) - Motivation comes from that fact that switches are increasingly the router interconnection of choice and it is fairly trivial to achieve this, by advertizing the reverse bandwidth (i.e. from the DR) - Next steps: . Two questions is this useful? Hole in RFC 3630 but also be a requirement from service provider? . Vendors to tell if this a reasonable solution. Discussions: ----------- - Acee Lindem: Put the question on the list? This is one is a bit more complicated than the previous TE extension (Rahuls), with two more vectors of information. - Acee Lindem: Do we want TE to this level of detail that keeps track of the type of switch ? - Dave Ward: There is a requirement to solve the problem, this is also a requirement for which Cisco is receiving input to define such kind of extensions. - Acee Lindem: Wonders if this has to be dealt here in the OSPF WG or in the TE WG? - (?): any admission control issue ? - Kireeti Kompella: Implementation needs a change to use this, backward compatible means that routers by seeing this, they don't pick out (of course they wouldn't be capable of using this); also by using a new TE LSA, router on the LAN would have to understand this TE LSA - concerning CAC issue suggests you read the draft - (?): interaction between admission control and RSVP ? - Kireeti Kompella: when TE extensions where defined, conclusion was that it doesn't make sense to say how RSVP-TE interacts with this, (this has not been done in OSPF-TE as well) some of the hints to do have been given in the document. Kireeti says it should be clear for the reader. - (?): put the information here asks the question of what is the added value of having this information to perform the CSPF. - Kireeti Kompella: Information is there to do admission control on the LAN. - George Swallow: It works in the fully point-switched case, but not in the case of cascaded switches. - Acee Lindem: Put also on the TE WG mailing list ********************************************************************* o Fred Baker (10 Mins): "Problem Statement for OSPF Extensions for Mobile Ad Hoc Routing" draft-baker-manet-ospf-problem-statement-00.txt - Problem statement for OSPF extensions for mobile ad hoc networks - Presentation: Discussions: ----------- - Rahul Aggarwal: High level comment, the argument on why OSPF is suitable is that one MANET network may co-exist with an existing LAN network -> so good to think about extensions The question is if meeting the MANET requirements generate a fundamental change is it not better to have a separate protocol? - Fred Baker: INRIA want to have their own protocol, but I want to keep both in one place - the only concern is related to the scalability properties of OSPF - note also the concern on the training issue (so ask if possible to just add a new interface). - Joseph Macker: A bit of history, in essence these protocol requirements seem applicable to OSPF, in addition people deploy and know how to manage it, it has homogeneous properties, and provides prefix summarization - here lot of interesting things in deploying OSPF for MANET networks seems to be stimulated by the development of this (new) problem statement. -> Is there a place for this development and in order to start this we need a problem statement document - Rahul Aggarwal: Arguments seem valid, but seeing the Baker's presentation, it also seems there are lot of changes to be expected. - Fred Baker: Not proposing to change the area hierarchy, what we are proposing is adding a MANET (radio) interface which is not behaving as a canonical "OSPF interface". - Rahul Aggarwal: We need probably more discussions. - (?): how do we address the bandwidth constraint issue? - Fred Baker: Turns out there are lot of things to be said here concerning this but we speak here in terms of Mbits . - INRIA rep: Disagrees strongly that they were not interested in OSPF, on the contrary INRIA put a lot attention and interest in OSPF, and are clearly also looking at OSPF extensions. - Alex Zinin: Refers to an understatement by "simply adding an interface" - before starting to speak about adding an interface, there are lot of things that may be impacted by adding such kind of interface and this even if it looks like very simple, it might not be the case. - Acee Lindem: Now OSPF is a general purpose protocol, if we take on all these requirements it will look like very different from what it is today? But I fear that if you take all the military requirements, I am not sure we will end up with the same protocol as we have today - Give the example of authentication in OSPFv3 using shared key multicast model - Thus take into account the military requirements may require a chain of changes from the existing documents. - Joseph Macker: We don't speak about military requirements, lot of these are like the existing requirements of an ISP, Baker's proposal was about optimization but wasn't pushed out and here proposal using a kind of stub within OSPF, being less intrusive but also less flexible - it is pretty easy to understand. - Sue Harres: Subsets have been worked out by the ISP's and how these changes can be allowed - point to the summarization issue. - Acee Lindem: Concurs on fears concerning summarization. - Sue Harres: Router protocols converge very fast today. - Acee Lindem: My fear was the change to the basic area hierarchy - Fred Baker: What I expect with the area boundary behavior, is that we will summarize at an area boundary as done now, but now information is spread, here departure by having a specific propagation w/i a specific area with longest prefix match first. - Sue Harres: Worry about the inter-region flooding, solved if there are multi-admin hierarchy, we have to gauge where we're getting benefits and problems. - Fred Baker: The big problem comes from the exponential explosion in messages and managing that growth (not the summarization). - Acee Lindem: there must be a defined hierarchy, the existing protocol will be summarizing when the entity moves from area to another. - Alex Zinin: Subsequent convergence in IGP is not the same wrt to the density of the topology - injecting information from an area to another while the majority of the nodes remains in the same area? - Rao: This would generate lot of dynamic state changes - using a list of neighbors depending on the region where the entity is located, this list would be pre-configured, but by moving from one region to another are you still keeping the same group of neighbors? - Fred Baker: Doesn't understand -> take offline - Joseph Macker: Idea with this is to find which WG can host the discussion here, proposes to discuss where people think this item has to go, key thing is to know if this protocol can be implemented using OSPF - Acee Lindem: Someone to send the list of drafts so that people can take a look about what we are talking about. *** Meeting is adjourned *** --------------010009050205040008090806-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 24 11:13:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14532 for ; Mon, 24 Nov 2003 11:13: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 <7.00C55F4A@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 11:13:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61799768 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 11:13:32 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 11:13:32 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 038FA8B6967 for ; Mon, 24 Nov 2003 08:13:31 -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 28415-05 for ; Mon, 24 Nov 2003 08:13:31 -0800 (PST) Received: from redback.com (unknown [155.53.6.49]) by prattle.redback.com (Postfix) with ESMTP id 63AE48B6966 for ; Mon, 24 Nov 2003 08:13:31 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20031120190002.21FC83E06@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FC22E1C.4030606@redback.com> Date: Mon, 24 Nov 2003 11:13:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on mib-update-07 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031120190002.21FC83E06@xmxpita.excite.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Don, See comments comments below. Don Goodspeed wrote: >All, > >Did a full re-review of the MIB and here are my comments: >1. For ospfNbrOptions, should we update the DESCRIPTION clause with >the current available options? >2. For ospfAsLsdbAdvertisement, the SYNTAX clause is incorrect. >Instead of SIZE(36), it needs to be SIZE(1..65535). >3. For ospfConfigErrorType, instead of moving noError every time >we add a new enum, just make noError to be zero. >4. Also for ospfConfigErrorType, in the DESCRIPTION, ospfConfig- >Error and ospfConfigVirtError need to have "If" in each. >5. Should we add additional error codes for: > a. badLsType -- something other than 1 thru 5 > This would indicate a type other than the types supported by the receiving router. Current OSPFv2 types include 1-7 and 9-11. > b. subnetMismatch -- for bcast links, or do we want to overload > netMaskMismatch? > c. xsumError -- when the packet contents do not match the OSPF > checksum, also when LSA content does not match LSA checksum > I wouldn't classify this as a configuration error. > d. badLengths -- when the advertised length of the OSPF packet > does not match the actual length of the received packet > We don't want to check this since there is a potential extension that requires that this isn't checked. >6. If 5a is adopted, then ospfPacketType needs an additional enum > for other(7) or unknown(7). > But 5 a) refers to LS types - not packet types. >7. For the NbrStateChange traps, should we add an additional >varbind for the event that caused the state change? This aids >when debugging a resetting adjacency to know that an sequence # >mismatch or a change in the options caused the adjacency to reset. > >Thanks, >Don > >_______________________________________________ >Join Excite! - http://www.excite.com >The most personalized portal on the Web! > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 24 15:57:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29231 for ; Mon, 24 Nov 2003 15:57:36 -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.00C563C8@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 15:57:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61823591 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 15:57:47 -0500 Received: from 207.159.120.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 15:57:47 -0500 Received: by xmxpita.excite.com (Postfix, from userid 110) id 3D6958AEC8; Mon, 24 Nov 2003 15:57:47 -0500 (EST) Received: from [64.47.48.10] by xprdmailfe2.nwk.excite.com via HTTP; Mon, 24 Nov 2003 15:57:47 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: <20031124205747.3D6958AEC8@xmxpita.excite.com> Date: Mon, 24 Nov 2003 15:57:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Comments on mib-update-07 Comments: To: acee@REDBACK.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Thanks for the reply. 5a. badLsType - I meant to put badPacketType (which means 1 thru 5 apply). Maybe we should also have a badLsType if we receive one other than 1-7 or 9-11! 5c. xsumError - Well, we can either overload the meaning of ospfConfigErrorType, or add a new ospfErrorType to deal with the non-configuration errors. However, this might mean adding a new ospfIfRcvBadPkt notification to handle receipt of these packets. 5d. badLengths - This is just to indicate receipt of a bad packet. Certain packet generators have been known to generate these as well as packets with checksum errors, and this is an indicator that such a bad packet was received. Once again, if we split off the ospfIfRcvBadPkt as a new notification, then this would be one of the possible bad packets. 6. see my reply to 5a above. We might need an additional ospfLsType attribute. Thanks, Don ======================= Hi Don, See comments comments below. Don Goodspeed wrote: >All, > >Did a full re-review of the MIB and here are my comments: >1. For ospfNbrOptions, should we update the DESCRIPTION clause with >the current available options? >2. For ospfAsLsdbAdvertisement, the SYNTAX clause is incorrect. >Instead of SIZE(36), it needs to be SIZE(1..65535). >3. For ospfConfigErrorType, instead of moving noError every time >we add a new enum, just make noError to be zero. >4. Also for ospfConfigErrorType, in the DESCRIPTION, ospfConfig- >Error and ospfConfigVirtError need to have "If" in each. >5. Should we add additional error codes for: > a. badLsType -- something other than 1 thru 5 > This would indicate a type other than the types supported by the receiving router. Current OSPFv2 types include 1-7 and 9-11. > b. subnetMismatch -- for bcast links, or do we want to overload > netMaskMismatch? > c. xsumError -- when the packet contents do not match the OSPF > checksum, also when LSA content does not match LSA checksum > I wouldn't classify this as a configuration error. > d. badLengths -- when the advertised length of the OSPF packet > does not match the actual length of the received packet > We don't want to check this since there is a potential extension that requires that this isn't checked. >6. If 5a is adopted, then ospfPacketType needs an additional enum > for other(7) or unknown(7). > But 5 a) refers to LS types - not packet types. >7. For the NbrStateChange traps, should we add an additional >varbind for the event that caused the state change? This aids >when debugging a resetting adjacency to know that an sequence # >mismatch or a change in the options caused the adjacency to reset. > >Thanks, >Don > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 24 16:12:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00373 for ; Mon, 24 Nov 2003 16:12: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 <13.00C56441@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 16:12:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61825626 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 16:12:20 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 16:12:13 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 205856544E4 for ; Mon, 24 Nov 2003 13:12:13 -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 03410-09 for ; Mon, 24 Nov 2003 13:12:12 -0800 (PST) Received: from redback.com (unknown [155.53.6.49]) by prattle.redback.com (Postfix) with ESMTP id 61A376544E3 for ; Mon, 24 Nov 2003 13:12:12 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20031124205747.3D6958AEC8@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FC2741D.1030904@redback.com> Date: Mon, 24 Nov 2003 16:11:57 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on mib-update-07 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031124205747.3D6958AEC8@xmxpita.excite.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Don, Don Goodspeed wrote: >Acee, > >Thanks for the reply. > >5a. badLsType - I meant to put badPacketType (which means 1 >thru 5 apply). > Okay. >Maybe we should also have a badLsType if we >receive one other than 1-7 or 9-11! > > >5c. xsumError - Well, we can either overload the meaning of >ospfConfigErrorType, or add a new ospfErrorType to deal with >the non-configuration errors. However, this might mean adding >a new ospfIfRcvBadPkt notification to handle receipt of these >packets. > At this point, I prefer the shortest route to WG Last Call so I'd be more in favor of overloading the type or doing nothing. > >5d. badLengths - This is just to indicate receipt of a bad >packet. Certain packet generators have been known to generate >these as well as packets with checksum errors, and this is >an indicator that such a bad packet was received. Once again, >if we split off the ospfIfRcvBadPkt as a new notification, >then this would be one of the possible bad packets. > Just so we don't check that the OSPF length is exactly the IP length. A valid check might be that it doesn't exceed the IP length. > >6. see my reply to 5a above. We might need an additional >ospfLsType attribute. > >Thanks, >Don > >======================= >Hi Don, > >See comments comments below. > >Don Goodspeed wrote: > > > >>All, >> >>Did a full re-review of the MIB and here are my comments: >>1. For ospfNbrOptions, should we update the DESCRIPTION clause with >>the current available options? >>2. For ospfAsLsdbAdvertisement, the SYNTAX clause is incorrect. >>Instead of SIZE(36), it needs to be SIZE(1..65535). >>3. For ospfConfigErrorType, instead of moving noError every time >>we add a new enum, just make noError to be zero. >>4. Also for ospfConfigErrorType, in the DESCRIPTION, ospfConfig- >>Error and ospfConfigVirtError need to have "If" in each. >>5. Should we add additional error codes for: >>a. badLsType -- something other than 1 thru 5 >> >> >> >This would indicate a type other than the types supported by the >receiving router. Current >OSPFv2 types include 1-7 and 9-11. > > > >>b. subnetMismatch -- for bcast links, or do we want to overload >>netMaskMismatch? >>c. xsumError -- when the packet contents do not match the OSPF >>checksum, also when LSA content does not match LSA checksum >> >> >> >I wouldn't classify this as a configuration error. > > > >>d. badLengths -- when the advertised length of the OSPF packet >>does not match the actual length of the received packet >> >> >> >We don't want to check this since there is a potential extension that >requires that this >isn't checked. > > > >>6. If 5a is adopted, then ospfPacketType needs an additional enum >>for other(7) or unknown(7). >> >> >> >But 5 a) refers to LS types - not packet types. > > > > >>7. For the NbrStateChange traps, should we add an additional >>varbind for the event that caused the state change? This aids >>when debugging a resetting adjacency to know that an sequence # >>mismatch or a change in the options caused the adjacency to reset. >> >>Thanks, >>Don >> >> >> > >_______________________________________________ >Join Excite! - http://www.excite.com >The most personalized portal on the Web! > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 24 20:14:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15069 for ; Mon, 24 Nov 2003 20:14:52 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C56BFE@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 20:15:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61844141 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 20:15:02 -0500 Received: from 202.43.216.208 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 20:15:02 -0500 Received: from [202.96.96.35] by web15405.mail.cnb.yahoo.com via HTTP; Tue, 25 Nov 2003 09:14:59 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20031125011459.31905.qmail@web15405.mail.cnb.yahoo.com> Date: Tue, 25 Nov 2003 09:14:59 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?q?Jing=20Shen?= Subject: Re: OSPF - IP Multicast interaction problem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FBA3F59.5020207@redback.com> Precedence: list Content-Transfer-Encoding: 8bit To our observation asymmetric routing seldomly appear in ISP's backbone network, as usually those links are ATM, 100Mbps/1000Mbps Ethernet or POS type. But we do observe asymmetric routing in inter-AS routing and QoS on the two paths differs much ( one with e2e traceroute lay around 350ms, the other about 1000ms with 50% packet loss rate). --- Acee Lindem µÄÕýÎÄ£º> Dear Mr Boot, > > If I undertstand your E-mail, you are requesting > that OSPF somehow > guarentee symmetric routing and > take some action in the face of asymmetric costs. I > (speaking as a WG > member) do not think this > is a problem that we should try and solve. In fact, > Isuspect that if we > looked hard enough there would > be IETF documents support not try to solve this > problem in OSPF. > > Thanks, > Acee > ' spamcontrol ' ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' __________________________________________________ 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 Tue Nov 25 14:57:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05288 for ; Tue, 25 Nov 2003 14:57: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 <2.00C583F1@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 14:57:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61962222 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 14:57:19 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 14:57:18 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A624A80E424 for ; Tue, 25 Nov 2003 11:57:17 -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 03089-04 for ; Tue, 25 Nov 2003 11:57:17 -0800 (PST) Received: from redback.com (unknown [155.53.6.33]) by prattle.redback.com (Postfix) with ESMTP id 972D080E422 for ; Tue, 25 Nov 2003 11:57:16 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040407080808000505050406" X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FC3B40B.6050902@redback.com> Date: Tue, 25 Nov 2003 14:56:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------040407080808000505050406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------040407080808000505050406 Content-Type: text/plain; name="manet.txt" Content-Disposition: inline; filename="manet.txt" Content-Transfer-Encoding: 7bit At the Minneapolis OSPF WG meeting Fred Baker presented the MANET requirements for OSPF. On the surface, MANET seems to imply some substantial changes to OSPF. These include changes to the hello protocol, DR election, flooding, LSA origination, and summarization. At this point, it seems we (the OSPF WG) has a number of ways in which we could proceed: 1. Do nothing - Leave MANET to the routing protocol(s) currently defined specifically for the MANET environment. 2. Define a OSPF-MANET boundary node which streamlines the interfaction between the chosen MANET protocol (hopefully one) and OSPF. 3. Define extensions to OSPFv3 which allow for one of more MANET clouds to connect to an OSPFv3 backbone. The extensions should be such that the base OSPFv3 network is insulated from the MANET extensions so that OSPFv3 nodes not supporting the extensions could co-exist outside the MANET cloud without changes. I say OSPFv3 here since everyone at the WG meeting agreed that IPv6 was a requirement for MANET and everyone at the WG meeting agreed that any substanitive extensions should only goto into OSPFv3. 4. Define a new protocol (OSPFv4) which attempts to satisfy the requirements for OSPFv3 and MANET. It should be as close to OSPFv3 as possible (but leaves out virtual links :^). 5. Other ideas (since the above are only the ones I thought of)? At this point, we need to discuss the direction which we want to take and, depending on the direction, how the work should be split between us and the MANET WG. I know the MANET WG is also anxious to make a decision. --------------040407080808000505050406-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 25 15:15:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06987 for ; Tue, 25 Nov 2003 15:15:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C58482@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 15:15:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61964423 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 15:15:49 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 15:15:49 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPKFkA03809 for ; Tue, 25 Nov 2003 22:15:46 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Nov 2003 22:15:46 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 14:13:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: OSPF WG Direction with respect to MANET Requirements Thread-Index: AcOzjmEQ1T6Yrj0oTt6uVT9NoRmu8wAAbqgA X-OriginalArrivalTime: 25 Nov 2003 20:13:54.0247 (UTC) FILETIME=[A6415D70:01C3B390] Message-ID: <8D260779A766FB4A9C1739A476F84FA401546F8D@daebe009.americas.nokia.com> Date: Tue, 25 Nov 2003 14:13:54 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > 4. Define a new protocol (OSPFv4) which attempts to satisfy > the requirements for OSPFv3 and MANET. It should be as > close to OSPFv3 as possible (but leaves out virtual > links :^). This protocol OSPFv4 will mean "OSPF for Manet" ? or this will be the next version of the OSPF protocol that will accomodate normal OSPF networks and MANET networks at the same time ?? Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 25 15:19:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07295 for ; Tue, 25 Nov 2003 15:19: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 <11.00C58303@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 15:19:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61964692 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 15:19:23 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 15:19:23 -0500 Received: (qmail 15071 invoked by uid 404); 25 Nov 2003 20:19:23 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.390092 secs); 25 Nov 2003 20:19:23 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 25 Nov 2003 20:19:22 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id PAA18654; Tue, 25 Nov 2003 15:19:22 -0500 Message-ID: <200311252019.PAA18654@bigbird.nj.us.utstar.com> Date: Tue, 25 Nov 2003 15:19:22 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists Comments: To: l3vpn@ietf.org Comments: cc: rcallon@juniper.net, erosen@CISCO.COM To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Wed, 29 Oct 2003 13:50:05 EST." <200310291850.NAA25555@bigbird.nj.us.utstar.com> Precedence: list The last call for this draft has ended. Comments received on the list will be incorporated into the next rev., before it goes to the ADs for review. --rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 25 15:31:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08238 for ; Tue, 25 Nov 2003 15:31: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 <0.00C585B4@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 15:31:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61965831 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 15:31:31 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 15:31:31 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AF5438272CE for ; Tue, 25 Nov 2003 12:31:29 -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 08286-08 for ; Tue, 25 Nov 2003 12:31:28 -0800 (PST) Received: from redback.com (unknown [155.53.6.23]) by prattle.redback.com (Postfix) with ESMTP id 0EF368272C1 for ; Tue, 25 Nov 2003 12:31:27 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA401546F8D@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FC3BC0E.9050600@redback.com> Date: Tue, 25 Nov 2003 15:31:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401546F8D@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh.Gupta@NOKIA.COM wrote: >> 4. Define a new protocol (OSPFv4) which attempts to satisfy >> the requirements for OSPFv3 and MANET. It should be as >> close to OSPFv3 as possible (but leaves out virtual >> links :^). >> >> > >This protocol OSPFv4 will mean "OSPF for Manet" ? or this will >be the next version of the OSPF protocol that will accomodate >normal OSPF networks and MANET networks at the same time ?? > I guess that is open for discussion and would depend on how compelling the protocol is for non-MANET environments. > >Regards >Mukesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 25 18:43:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18350 for ; Tue, 25 Nov 2003 18:43: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 <4.00C588EB@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 18:43:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61984361 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 18:43:17 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 18:43:17 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAPNhFw5013542 for ; Tue, 25 Nov 2003 15:43:15 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANX78233; Tue, 25 Nov 2003 15:43:13 -0800 (PST) X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 References: <3FC3B40B.6050902@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > Date: Tue, 25 Nov 2003 15:35:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Fred Baker Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC3B40B.6050902@redback.com> Precedence: list Acee: At 11:56 AM 11/25/2003, Acee Lindem wrote: > 1. Do nothing - Leave MANET to the routing protocol(s) currently > defined specifically for the MANET environment. > > 2. Define a OSPF-MANET boundary node which streamlines the > interfaction between the chosen MANET protocol (hopefully > one) and OSPF. > > 3. Define extensions to OSPFv3 which allow for one of more MANET > clouds to connect to an OSPFv3 backbone. The extensions should > be such that the base OSPFv3 network is insulated from the MANET > extensions so that OSPFv3 nodes not supporting the extensions > could co-exist outside the MANET cloud without changes. I say > OSPFv3 here since everyone at the WG meeting agreed that IPv6 > was a requirement for MANET and everyone at the WG meeting > agreed that any substanitive extensions should only goto into > OSPFv3. > > 4. Define a new protocol (OSPFv4) which attempts to satisfy > the requirements for OSPFv3 and MANET. It should be as > close to OSPFv3 as possible (but leaves out virtual > links :^). I think there is at least one other approach that has been suggested, which you have overlooked. IMHO, it is the simplest model. In Alex's comments to Abhay Roy, he talked about a Manet Area. This approach seemed to convolute the fundamental concepts of OSPF. Operationally, one certainly wants to tie a string around the set of router interfaces that form a manet network or part of one, both to constrain their disruption of other parts of the network and to constrain the interactions between similar-but-different manet networks. But mobile-ad-hoc-ness is not fundamentally a characteristic of the area. The area is a standard OSPF construct that one uses at an administrative or policy boundary to ensure that proper summarization happens and unnecessary changes are not propagated. In your remarks, you talk about "extensions to OSPFv3 which allow for one of more MANET clouds to connect to an OSPFv3 backbone". The manet cloud, from the sound of it, is using another routing protocol. If you want to do that, we can already do that - leaking routes between routing protocols is something we pretty standardly do. But route leaking is not very pretty, and we were hoping to not have to re-invent OSPF (areas, metrics, multi-topology routing, and all that) to accomplish this. Heck, if we wanted to go there, we would simply extend EIGRP, or adopt OLSR and extend it with the things it needs to be deployable on a wide scale. What we are proposing is something much simpler. We would like to add a manet interface type to OSPFv3. The addition of this interface capability is entirely optional - an implementation that never expects to be deployed in a radio network need not implement it, and can fully expect to interoperate with implementations that have implemented it, on their non-radio interfaces. The MANET interface is different from a standard serial interface (as it has multiple neighbors) and different from a LAN interface (it has no DR). I don't see that as a fundamental impediment; remember that about eleven years ago I pointed out that the NBMA interface didn't work very well in Frame Relay networks of the day and proposed what we now call the point-to-multipoint interface. Adapting OSPF to new interface technologies (F/R being fairly new then) is something that has always been integral to OSPF's development. To throw out the idea of a manet interface because it is different - well, that would be a step in conservatism that would cause me a great deal of concern. I understand and very much support the conservatism that says "don't break what already works". But conservatism that prevents OSPF from addressing new requirements declares OSPF an obsolete protocol, and forces new requirements into a new protocol. I don't think of OSPF as obsolete... Can you tell me why adding a manet interface to OSPF is not on of the options you are willing to consider? From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 25 22:13:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23323 for ; Tue, 25 Nov 2003 22:13: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 <16.00C58B8A@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 22:13:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62002981 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 22:13:13 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 22:13:12 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E688F3AF84A for ; Tue, 25 Nov 2003 19:13:11 -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 14074-01 for ; Tue, 25 Nov 2003 19:13:11 -0800 (PST) Received: from redback.com (unknown [155.53.6.23]) by prattle.redback.com (Postfix) with ESMTP id CBD353AF846 for ; Tue, 25 Nov 2003 19:13:10 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3FC3B40B.6050902@redback.com> <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FC41A34.9000002@redback.com> Date: Tue, 25 Nov 2003 22:12:52 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > Precedence: list Content-Transfer-Encoding: 7bit Fred, See inline below. Fred Baker wrote: > Acee: > > At 11:56 AM 11/25/2003, Acee Lindem wrote: > >> 1. Do nothing - Leave MANET to the routing protocol(s) currently >> defined specifically for the MANET environment. >> >> 2. Define a OSPF-MANET boundary node which streamlines the >> interfaction between the chosen MANET protocol (hopefully >> one) and OSPF. >> >> 3. Define extensions to OSPFv3 which allow for one of more MANET >> clouds to connect to an OSPFv3 backbone. The extensions should >> be such that the base OSPFv3 network is insulated from the MANET >> extensions so that OSPFv3 nodes not supporting the extensions >> could co-exist outside the MANET cloud without changes. I say >> OSPFv3 here since everyone at the WG meeting agreed that IPv6 >> was a requirement for MANET and everyone at the WG meeting >> agreed that any substanitive extensions should only goto into >> OSPFv3. >> >> 4. Define a new protocol (OSPFv4) which attempts to satisfy >> the requirements for OSPFv3 and MANET. It should be as >> close to OSPFv3 as possible (but leaves out virtual >> links :^). > > > I think there is at least one other approach that has been suggested, > which > you have overlooked. IMHO, it is the simplest model. > > In Alex's comments to Abhay Roy, he talked about a Manet Area. This > approach seemed to convolute the fundamental concepts of OSPF. This would be an instance of #3. A separate area type may or may not be necessary to insulate non-MANET routers from MANET routers. > > Operationally, one certainly wants to tie a string around the set of > router > interfaces that form a manet network or part of one, both to constrain > their disruption of other parts of the network and to constrain the > interactions between similar-but-different manet networks. But > mobile-ad-hoc-ness is not fundamentally a characteristic of the area. The > area is a standard OSPF construct that one uses at an administrative or > policy boundary to ensure that proper summarization happens and > unnecessary > changes are not propagated. I agree that a MANET area is not cast in stone. However, on the surface it would seem like a good way to segregate the MANET extensions from base OSPFv3. > > > In your remarks, you talk about "extensions to OSPFv3 which allow for one > of more MANET clouds to connect to an OSPFv3 backbone". The manet cloud, > from the sound of it, is using another routing protocol. If you want > to do > that, we can already do that - leaking routes between routing > protocols is > something we pretty standardly do. This is option #1. There are 3 other options listed. > But route leaking is not very pretty, > and we were hoping to not have to re-invent OSPF (areas, metrics, > multi-topology routing, and all that) to accomplish this. Heck, if we > wanted to go there, we would simply extend EIGRP, or adopt OLSR and > extend > it with the things it needs to be deployable on a wide scale. > > What we are proposing is something much simpler. We would like to add a > manet interface type to OSPFv3. The addition of this interface capability > is entirely optional - an implementation that never expects to be > deployed > in a radio network need not implement it, and can fully expect to > interoperate with implementations that have implemented it, on their > non-radio interfaces. > > The MANET interface is different from a standard serial interface (as it > has multiple neighbors) and different from a LAN interface (it has no > DR). > I don't see that as a fundamental impediment; remember that about eleven > years ago I pointed out that the NBMA interface didn't work very well in > Frame Relay networks of the day and proposed what we now call the > point-to-multipoint interface. Adapting OSPF to new interface > technologies > (F/R being fairly new then) is something that has always been integral to > OSPF's development. To throw out the idea of a manet interface because it > is different - well, that would be a step in conservatism that would > cause > me a great deal of concern. I understand and very much support the > conservatism that says "don't break what already works". But conservatism > that prevents OSPF from addressing new requirements declares OSPF an > obsolete protocol, and forces new requirements into a new protocol. I > don't > think of OSPF as obsolete... > > Can you tell me why adding a manet interface to OSPF is not on of the > options you are willing to consider? If the MANET interface can be added without significant modification to the basic OSPF mechanisms (e.g. the P2MP interface was a natural extension sinnce it operates very similar to a mesh of P2Ps) then this would be an instance of option #3. If OSPFv3 will need to changed significantly to meet the MANET requirements then this should be a separate option (option #5). Anyway, it for the OSPF WG as a whole to decide. Maybe it is best to put forth the MANET interface proposal for technical review. Thanks, Acee > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 25 23:37:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24611 for ; Tue, 25 Nov 2003 23:37: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 <22.00C58EE0@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 23:37:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62009170 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 23:37:52 -0500 Received: from 63.65.120.65 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 23:37:52 -0500 Received: (covad.net 6547 invoked from network); 26 Nov 2003 04:37:47 -0000 Received: from unknown (HELO vishwas) (61.95.163.161) by sun-qmail08 with SMTP; 26 Nov 2003 04:37:46 -0000 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <006301c3b3f4$f1f47db0$730aa8c0@vishwas> Date: Wed, 26 Nov 2003 10:11:49 +0200 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > Precedence: list Content-Transfer-Encoding: 7bit Hi Acee/Fred, I have just started looking into ad-hoc networks so excuse me if I miss the point. I browsed thru the slides http://www.ietf.org/proceedings/02mar/slides/manet-1/sld005.htm and checked the problem statement. I think new LSA types/dynamic metric calculations(can be internal to an implementation) would need to be added too besides the changes Acee has listed. I am not sure what changes are required for the DR election, are you suggesting that the STA(AP) with the route to the ABR becomes the DR. Ad-hoc networks are IBSS LAN's, they do not have a DS. Why would we need to have connection of Manet area to other Integrated LANs(I see the point in Fred's slides too)? Is it for intermittently connecting to the internet, when the cluster can(when it would not be an ad-hoc network)? I have another doubt, is there an assumption that all STA's support IPv6? Are any new security extensions also planned to be defined? I feel we should proceed with Point 3 in Acee's mail. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Fred Baker Sent: Wednesday, November 26, 2003 1:35 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF WG Direction with respect to MANET Requirements Acee: At 11:56 AM 11/25/2003, Acee Lindem wrote: > 1. Do nothing - Leave MANET to the routing protocol(s) currently > defined specifically for the MANET environment. > > 2. Define a OSPF-MANET boundary node which streamlines the > interfaction between the chosen MANET protocol (hopefully > one) and OSPF. > > 3. Define extensions to OSPFv3 which allow for one of more MANET > clouds to connect to an OSPFv3 backbone. The extensions should > be such that the base OSPFv3 network is insulated from the MANET > extensions so that OSPFv3 nodes not supporting the extensions > could co-exist outside the MANET cloud without changes. I say > OSPFv3 here since everyone at the WG meeting agreed that IPv6 > was a requirement for MANET and everyone at the WG meeting > agreed that any substanitive extensions should only goto into > OSPFv3. > > 4. Define a new protocol (OSPFv4) which attempts to satisfy > the requirements for OSPFv3 and MANET. It should be as > close to OSPFv3 as possible (but leaves out virtual > links :^). I think there is at least one other approach that has been suggested, which you have overlooked. IMHO, it is the simplest model. In Alex's comments to Abhay Roy, he talked about a Manet Area. This approach seemed to convolute the fundamental concepts of OSPF. Operationally, one certainly wants to tie a string around the set of router interfaces that form a manet network or part of one, both to constrain their disruption of other parts of the network and to constrain the interactions between similar-but-different manet networks. But mobile-ad-hoc-ness is not fundamentally a characteristic of the area. The area is a standard OSPF construct that one uses at an administrative or policy boundary to ensure that proper summarization happens and unnecessary changes are not propagated. In your remarks, you talk about "extensions to OSPFv3 which allow for one of more MANET clouds to connect to an OSPFv3 backbone". The manet cloud, from the sound of it, is using another routing protocol. If you want to do that, we can already do that - leaking routes between routing protocols is something we pretty standardly do. But route leaking is not very pretty, and we were hoping to not have to re-invent OSPF (areas, metrics, multi-topology routing, and all that) to accomplish this. Heck, if we wanted to go there, we would simply extend EIGRP, or adopt OLSR and extend it with the things it needs to be deployable on a wide scale. What we are proposing is something much simpler. We would like to add a manet interface type to OSPFv3. The addition of this interface capability is entirely optional - an implementation that never expects to be deployed in a radio network need not implement it, and can fully expect to interoperate with implementations that have implemented it, on their non-radio interfaces. The MANET interface is different from a standard serial interface (as it has multiple neighbors) and different from a LAN interface (it has no DR). I don't see that as a fundamental impediment; remember that about eleven years ago I pointed out that the NBMA interface didn't work very well in Frame Relay networks of the day and proposed what we now call the point-to-multipoint interface. Adapting OSPF to new interface technologies (F/R being fairly new then) is something that has always been integral to OSPF's development. To throw out the idea of a manet interface because it is different - well, that would be a step in conservatism that would cause me a great deal of concern. I understand and very much support the conservatism that says "don't break what already works". But conservatism that prevents OSPF from addressing new requirements declares OSPF an obsolete protocol, and forces new requirements into a new protocol. I don't think of OSPF as obsolete... Can you tell me why adding a manet interface to OSPF is not on of the options you are willing to consider? From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 26 12:16:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17924 for ; Wed, 26 Nov 2003 12:16: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 <11.00C59B80@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 12:16:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62088305 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 12:16:19 -0500 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 12:06:19 -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 JAA27521 for ; Wed, 26 Nov 2003 09:06:15 -0800 (PST) Received: from slb-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 JAA10223 for ; Wed, 26 Nov 2003 09:06:18 -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 hAQH5lG02654 for ; Wed, 26 Nov 2003 09:05:47 -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, 26 Nov 2003 09:05:29 -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: Re: OSPF WG Direction with respect to MANET Requirements Thread-Index: AcO0P33eL6HqDWPoRCexRJVmNROt5g== X-OriginalArrivalTime: 26 Nov 2003 17:05:29.0036 (UTC) FILETIME=[7E3CD0C0:01C3B43F] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5E7F@xch-nw-27.nw.nos.boeing.com> Date: Wed, 26 Nov 2003 09:05:28 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > From: Vishwas Manral > Subject: Re: OSPF WG Direction with respect to MANET Requirements > In-Reply-To: <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com = > > >=20 > I think new LSA types/dynamic metric calculations(can be internal to = an > implementation) would need to be added too besides the changes Acee = has > listed. I am not sure what changes are required for the DR election, = are you > suggesting that the STA(AP) with the route to the ABR becomes the DR. It is not strictly necessary to change LSA types. We have an OSPFv2=20 implementation in the spirit of Fred's proposal (new interface type) = that does not change LSAs at all, and is fully backward compatible with legacy routers. It does not require splitting the MANET cloud into a separate area. The LSAs correspond to a point-to-multipoint subnet,=20 but the flooding internal to the MANET subnet behaves like OLSR. http://www.ietf.org/internet-drafts/draft-spagnolo-manet-ospf-wireless-in= terface-00.txt Tom From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 27 05:31:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02705 for ; Thu, 27 Nov 2003 05:31:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C5AE02@cherry.ease.lsoft.com>; Thu, 27 Nov 2003 5:31:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62158252 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Nov 2003 05:31:15 -0500 Received: from 61.95.163.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Nov 2003 05:31:14 -0500 Received: from vishwas ([192.168.10.115]) by sinettds.sinettws (8.12.5/8.12.5) with SMTP id hARAUVNc019852 for ; Thu, 27 Nov 2003 16:00:32 +0530 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MS-TNEF-Correlator: 00000000E61A1023E6B026439CE2315114A2C0D2845C4E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <005201c3b4ef$64440a70$730aa8c0@vishwas> Date: Thu, 27 Nov 2003 16:04:35 +0200 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5E7F@xch-nw-27.nw.nos.boeing.com> Precedence: list Content-Transfer-Encoding: 7bit Tom, I checked the link you sent a bit. I may be wrong here but if we model our interfaces as P2MP, we will not have a transit link from the Manet Area at all, as we are not going above 2-way state in which case the only link for the P2MP network will be (as per 2328) o A single Type 3 link (stub network) is added with Link ID set to the router's own IP interface address, Link Data set to the mask 0xffffffff (indicating a host route), and cost set to 0. And as the generation and routing table calculations don't have any change how would you have the route through a wireless network. So according to 2.1.1 the table would be **FROM** +---+ +---+ |RT3| |RT4| |RT3|RT4|RT5|RT6| +---+ +---+ * -------------------- I3| |I4 * RT3| | | | | +----------------------+ T RT4| | | | | I5| |I6 O RT5| | | | | +---+ +---+ * RT6| | | | | |RT5| |RT6| * I3| X | | | | +---+ +---+ I4| | X | | | I5| | | X | | I6| | | | X | Only when a 2-way check passes do we check the adjacent neighbors LSA's, but that will never happen in the case here. In my view the SPF and the condition of generation of links on LSA's will have to change too. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Henderson, Thomas R Sent: Wednesday, November 26, 2003 7:05 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF WG Direction with respect to MANET Requirements > From: Vishwas Manral > Subject: Re: OSPF WG Direction with respect to MANET Requirements > In-Reply-To: <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > > > > I think new LSA types/dynamic metric calculations(can be internal to an > implementation) would need to be added too besides the changes Acee has > listed. I am not sure what changes are required for the DR election, are you > suggesting that the STA(AP) with the route to the ABR becomes the DR. It is not strictly necessary to change LSA types. We have an OSPFv2 implementation in the spirit of Fred's proposal (new interface type) that does not change LSAs at all, and is fully backward compatible with legacy routers. It does not require splitting the MANET cloud into a separate area. The LSAs correspond to a point-to-multipoint subnet, but the flooding internal to the MANET subnet behaves like OLSR. http://www.ietf.org/internet-drafts/draft-spagnolo-manet-ospf-wireless-inter face-00.txt Tom From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 28 10:24:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01441 for ; Fri, 28 Nov 2003 10:24: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 <20.00C5C787@cherry.ease.lsoft.com>; Fri, 28 Nov 2003 10:24:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62305056 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 28 Nov 2003 10:24:17 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Nov 2003 10:24:17 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 28 Nov 2003 07:26:11 +0000 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hASFOEDM013438 for ; Fri, 28 Nov 2003 10:24:14 -0500 (EST) Received: from localhost (rtp-vpn2-409.cisco.com [10.82.241.153]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA05102 for ; Fri, 28 Nov 2003 10:24:12 -0500 (EST) References: <3FC3B40B.6050902@redback.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 28 Nov 2003 10:24:12 -0500 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC3B40B.6050902@redback.com> Precedence: list 3. Define extensions to OSPFv3 which allow for one of more MANET clouds to connect to an OSPFv3 backbone. The extensions should be such that the base OSPFv3 network is insulated from the MANET extensions so that OSPFv3 nodes not supporting the extensions could co-exist outside the MANET cloud without changes. I say OSPFv3 here since everyone at the WG meeting agreed that IPv6 was a requirement for MANET and everyone at the WG meeting agreed that any substanitive extensions should only goto into OSPFv3. This would be my preference, at an interface level. We could call this an "area" level, and it might be an area boundary to the "wire line" ospfv3 cloud, but I think that from the MANET side, it's slightly dangerous to think of it as an area border, since the concept of a flooding domain/area becomes much more ambiguous. So, I think I would put it this way: -- Define extensions to OSPFv3 that will not impact current wire-line implementations. -- Bound these extensions at an interface and/or area border, depending on what investigation turns up in technical discussion, so the wire line side is not impacted (see above). And finally: 4. Define a new protocol (OSPFv4) which attempts to satisfy the requirements for OSPFv3 and MANET. It should be as close to OSPFv3 as possible (but leaves out virtual links :^). -- Once these extensions are completed, tested, and proven to work, consider moving any such extensions back into OSPF as it might be considered advantageous at some future point. So, the way I would approach it: -- Do a small "technical working group," so that those interested can go "off on the side" in a public way without making the ospf wg mailing list, itself, a major thoroughfare. I suspect that just about everyone would subscribe to this "off on the side" list, which is okay, as long as it seperates the traffic, most likely. And, we could conciously bring in the MANET people in this way. -- Set some timetable/goal for producing output, some set of drafts, possible competing ones, that will be presented at some definite meeting in the future. -- Let the sparks fly. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 28 15:07:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09051 for ; Fri, 28 Nov 2003 15:07: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 <6.00C5CB70@cherry.ease.lsoft.com>; Fri, 28 Nov 2003 15:07:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62317477 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 28 Nov 2003 15:07:43 -0500 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Nov 2003 15:07:43 -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 MAA19680 for ; Fri, 28 Nov 2003 12:07:38 -0800 (PST) Received: from blv-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 MAA12831 for ; Fri, 28 Nov 2003 12:07:42 -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 hASK5kq17426 for ; Fri, 28 Nov 2003 12:05:46 -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, 28 Nov 2003 12:06:02 -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: OSPF WG Direction with respect to MANET Requirements Thread-Index: AcO00cKK3wQgoiWuReynIdB7T1Av7gBFfjYA X-OriginalArrivalTime: 28 Nov 2003 20:06:02.0829 (UTC) FILETIME=[0C81EFD0:01C3B5EB] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1AB@xch-nw-27.nw.nos.boeing.com> Date: Fri, 28 Nov 2003 12:06:02 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vishwas Manral [mailto:vishwas@SINETT.COM] > Sent: Thursday, November 27, 2003 6:05 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: OSPF WG Direction with respect to MANET Requirements >=20 >=20 > Tom, >=20 > I checked the link you sent a bit. >=20 > I may be wrong here but if we model our interfaces as P2MP,=20 > we will not have > a transit link from the Manet Area at all, as we are not=20 > going above 2-way > state in which case the only link for the P2MP network will=20 > be (as per 2328) >=20 > o A single Type 3 link (stub network) is added with > Link ID set to the router's own IP interface > address, Link Data set to the mask 0xffffffff > (indicating a host route), and cost set to 0. We do the additional step as in Point-to-Multipoint: o For each fully adjacent neighbor associated with the interface, add an additional Type 1 link (point-to- point) with Link ID set to the Router ID of the neighboring router, Link Data set to the IP interface address and cost equal to the interface's configured output cost. This probably should be clarified further in the draft in section 12-- basically, on a wireless subnet, once neighbors get to state 2-Way (seeing themselves in each other's Hellos) they are considered "fully adjacent" from the perspective of generating LSAs (since they skip database exchange) and can advertise Type 1 links between them. =20 Tom