From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 04 08:59:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fJb-0006lO-EX for ospf-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:59:15 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05470 for ; Thu, 4 Aug 2005 08:59:13 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010BE71B@cherry.ease.lsoft.com>; Thu, 4 Aug 2005 8:59:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81399368 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Aug 2005 08:59:03 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 4 Aug 2005 08:59:03 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0fJN-000L0n-DF for ospf@peach.ease.lsoft.com; Thu, 04 Aug 2005 12:59:02 +0000 X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1288871029.20050804055849@psg.com> Date: Thu, 4 Aug 2005 05:58:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: OSPFv3 fwd'ing address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Folks- For the problem with the forwarding address that I mentioned during the meeting, please see the following thread: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0203&L=OSPF&P=R2888&I=-3 -- Alex From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 04 09:33:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fql-00031V-3c for ospf-archive@megatron.ietf.org; Thu, 04 Aug 2005 09:33:31 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10073 for ; Thu, 4 Aug 2005 09:33:29 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010BE818@cherry.ease.lsoft.com>; Thu, 4 Aug 2005 9:33:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81402601 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Aug 2005 09:33:28 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 4 Aug 2005 09:33:28 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 Aug 2005 06:33:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,166,1120460400"; d="scan'208"; a="4669104:sNHT22395856" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j74DWlRN026717 for ; Thu, 4 Aug 2005 09:33:25 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 09:33:20 -0400 Received: from [10.82.216.240] ([10.82.216.240]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 09:33:20 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1288871029.20050804055849@psg.com> <42F2145D.8020205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2005 13:33:20.0526 (UTC) FILETIME=[145412E0:01C598F9] Message-ID: <42F21920.1040301@cisco.com> Date: Thu, 4 Aug 2005 09:33:20 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 fwd'ing address To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42F2145D.8020205@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Alex, So I did understand the comment - see inline. Acee Lindem wrote: > Alex Zinin wrote: > >> Folks- >> >> For the problem with the forwarding address that I mentioned during the >> meeting, please see the following thread: >> >> http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0203&L=OSPF&P=R2888&I=-3 >> >> >> >> > > *Date:* Tue, 12 Mar 2002 06:26:54 -0500 > *Reply-To:* Mailing List <[log in to unmask]> > *Sender:* Mailing List <[log in to unmask]> > *From:* "Kwiatkowski, Jacek" <[log in to unmask]> > *Subject:* Issues in OSPFv3 (RFC2740) > > 1) RFC 2740 specifies two options bits: V6-bit and R-bit. These bits > are set in Router-LSAs and Link-LSAs (also in Network-LSAs and > Inter-Area- Router-LSAs if these bits are set in associated LSAs). > Section 3.8.1 does not specify how to use these V6-bit and R-bit > during routing table calculation. I understand that all LSAs without > V6-bit should be ignored during calculation. Handling of R-bit is a > bit more complicated. A host may advertise addresses that are not > advertised by other OSPF routers. I think LSAs whose R-bit is reset > should not be ignored. A vertex without R-bit should be added to > shortest path tree as a leaf. It can be achieved if a calculating > router will ignore all links of a such vertex after the vertex was > added to the shortest path tree. During next stage, when > intra-area-prefix-LSA associated with vertex without R-bit is > examined, only prefixes whose LA-bit is set should be included in the > calculation. I think it is also worth to write in the specification > how OSPF should work as a host. This has been clarified in the 2740 respin. > 2) Forwarding address in AS-external-LSA. In IPv4, the next hop > address of a route can be any unicast address. In IPv6, the next hop > of a route must be link-local address (RFC 2461, section 8). This > requirement causes two problems: - OSPF cannot determine a global > address of a neighboring router. The next hop of a route is a > link-local address and OSPF must use a global address for the > forwarding address in AS-external-LSA. - If a forwarding address is > set in AS-external-LSA, a router connected to a common link with the > router advertised in the forwarding address has to translate the > forwarding address (global) to the next hop address (link- local). But > the router does not have data to make translation. Right - as I stated at the meeting, we will NEVER use a link-local address as a forwarding address. Hence, the forwarding address advertisement is effectively disabled - except for NSSAs where we must choose of our global addresses as a forwarding address. Perhaps, I've let my own aversion to the implementation complexity added by forwarding addresses :^) The problem here is that OSPFv3 may or may not have access to the global unicast address for the next-hop. If the next-hop router is running OSPFv3 - then there will be a link-local LSA. However, that begs the question of why this is not the router advertising the external prefix. The only reliable way would be to require interaction with IPv6 ND (neighbor discovery) in order to determine a global address to advertise. Architecturally, I don't like adding this dependency (and none of the implementations I've been associated with do this yet). Comments? Could I be missing something simple? Thanks, Acee > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 04 09:38:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fvy-00045K-Mz for ospf-archive@megatron.ietf.org; Thu, 04 Aug 2005 09:38:54 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10514 for ; Thu, 4 Aug 2005 09:38:52 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010BE83E@cherry.ease.lsoft.com>; Thu, 4 Aug 2005 9:38:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81402838 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Aug 2005 09:38:52 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 4 Aug 2005 09:38:51 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0fvu-000OQM-Nv; Thu, 04 Aug 2005 13:38:51 +0000 X-Priority: 3 (Normal) References: <1288871029.20050804055849@psg.com> <42F2145D.8020205@cisco.com> <42F21920.1040301@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <571507541.20050804063839@psg.com> Date: Thu, 4 Aug 2005 06:38:39 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv3 fwd'ing address Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42F21920.1040301@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, >> 2) Forwarding address in AS-external-LSA. In IPv4, the next hop >> address of a route can be any unicast address. In IPv6, the next hop >> of a route must be link-local address (RFC 2461, section 8). This >> requirement causes two problems: - OSPF cannot determine a global >> address of a neighboring router. The next hop of a route is a >> link-local address and OSPF must use a global address for the >> forwarding address in AS-external-LSA. - If a forwarding address is >> set in AS-external-LSA, a router connected to a common link with the >> router advertised in the forwarding address has to translate the >> forwarding address (global) to the next hop address (link- local). But >> the router does not have data to make translation. > Right - as I stated at the meeting, we will NEVER use a link-local > address as a forwarding address. That's not the case above, though. In the following scenario: [R3] | ------------ | | [R1] [R2] R1 originates an ASE with R3's global address GA1 as the fwd addr. When R2 calculates its route, it will have to translate GA1 to some link-local next-hop LA1, but it has no info in OSPF for this. I'll wait to comment on the rest for now :) -- Alex > Hence, the forwarding > address advertisement is effectively disabled - except for NSSAs where > we must choose of our global addresses as a > forwarding address. Perhaps, I've let my own aversion to the > implementation complexity added by forwarding addresses :^) > The problem here is that OSPFv3 may or may not have access to the global > unicast address for the next-hop. If the > next-hop router is running OSPFv3 - then there will be a link-local LSA. > However, that begs the question of why this is > not the router advertising the external prefix. The only reliable way > would be to require interaction with > IPv6 ND (neighbor discovery) in order to determine a global address to > advertise. Architecturally, I don't like adding this > dependency (and none of the implementations I've been associated with do > this yet). Comments? Could I be missing > something simple? > Thanks, > Acee >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 04 09:53:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gAP-0001bT-Hb for ospf-archive@megatron.ietf.org; Thu, 04 Aug 2005 09:53:49 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11702 for ; Thu, 4 Aug 2005 09:53:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010BE6EF@cherry.ease.lsoft.com>; Thu, 4 Aug 2005 9:53:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81403439 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Aug 2005 09:53:32 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 4 Aug 2005 09:53:32 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 04 Aug 2005 09:53:33 -0400 X-IronPort-AV: i="3.95,166,1120449600"; d="scan'208"; a="65211636:sNHT35633100" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j74DrTT6001122; Thu, 4 Aug 2005 09:53:30 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 09:53:24 -0400 Received: from [10.82.216.240] ([10.82.216.240]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 09:53:24 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1288871029.20050804055849@psg.com> <42F2145D.8020205@cisco.com> <42F21920.1040301@cisco.com> <571507541.20050804063839@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2005 13:53:24.0583 (UTC) FILETIME=[E2009770:01C598FB] Message-ID: <42F21DD3.9010102@cisco.com> Date: Thu, 4 Aug 2005 09:53:23 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 fwd'ing address Comments: To: Alex Zinin To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <571507541.20050804063839@psg.com> Precedence: list Content-Transfer-Encoding: 7bit Alex Zinin wrote: >Acee, > > > >>>2) Forwarding address in AS-external-LSA. In IPv4, the next hop >>>address of a route can be any unicast address. In IPv6, the next hop >>>of a route must be link-local address (RFC 2461, section 8). This >>>requirement causes two problems: - OSPF cannot determine a global >>>address of a neighboring router. The next hop of a route is a >>>link-local address and OSPF must use a global address for the >>>forwarding address in AS-external-LSA. - If a forwarding address is >>>set in AS-external-LSA, a router connected to a common link with the >>>router advertised in the forwarding address has to translate the >>>forwarding address (global) to the next hop address (link- local). But >>>the router does not have data to make translation. >>> >>> > > > >>Right - as I stated at the meeting, we will NEVER use a link-local >>address as a forwarding address. >> >> > >That's not the case above, though. In the following scenario: > > [R3] > | > ------------ > | | > [R1] [R2] > > R1 originates an ASE with R3's global address GA1 as the fwd addr. When R2 > calculates its route, it will have to translate GA1 to some link-local > next-hop LA1, but it has no info in OSPF for this. > > Ok - let's say R3 is in a different routing domain and R1's OSPFv3 does go through some measure (possibly extraordinary) to determine a valid global address for R3's associated interface and assure the address is associated with a global prefix advertised internal to OSPFv3. R2 would also have to determine the prefix is directly connected (a route lookup) and then go to neighbor discovery to map the global address to the link-local address. I can thnk of other solutions but they would require more information advertised with the forwarding address. Thanks, Acee >I'll wait to comment on the rest for now :) > >-- >Alex > > > > >>Hence, the forwarding >>address advertisement is effectively disabled - except for NSSAs where >>we must choose of our global addresses as a >>forwarding address. Perhaps, I've let my own aversion to the >>implementation complexity added by forwarding addresses :^) >>The problem here is that OSPFv3 may or may not have access to the global >>unicast address for the next-hop. If the >>next-hop router is running OSPFv3 - then there will be a link-local LSA. >>However, that begs the question of why this is >>not the router advertising the external prefix. The only reliable way >>would be to require interaction with >>IPv6 ND (neighbor discovery) in order to determine a global address to >>advertise. Architecturally, I don't like adding this >>dependency (and none of the implementations I've been associated with do >>this yet). Comments? Could I be missing >>something simple? >> >> > > > >>Thanks, >>Acee >> >> > > > >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 04 13:38:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jg0-0007qg-2j for ospf-archive@megatron.ietf.org; Thu, 04 Aug 2005 13:38:40 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26265 for ; Thu, 4 Aug 2005 13:38:36 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010BEC87@cherry.ease.lsoft.com>; Thu, 4 Aug 2005 13:38:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81423214 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Aug 2005 13:38:32 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 4 Aug 2005 13:38:32 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0jfr-000Ht0-Gg; Thu, 04 Aug 2005 17:38:31 +0000 X-Priority: 3 (Normal) References: <1288871029.20050804055849@psg.com> <42F2145D.8020205@cisco.com> <42F21920.1040301@cisco.com> <571507541.20050804063839@psg.com> <42F21DD3.9010102@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <5410120267.20050804103819@psg.com> Date: Thu, 4 Aug 2005 10:38:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv3 fwd'ing address Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42F21DD3.9010102@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit > Ok - let's say R3 is in a different routing domain and R1's OSPFv3 does > go through some measure (possibly extraordinary) to determine a valid > global address for R3's associated interface and assure the address is > associated with a global prefix advertised internal to OSPFv3. R2 would > also have to determine the prefix is directly connected (a route lookup) > and then go to neighbor discovery to map the global address to the > link-local address. I can thnk of other solutions but they would require > more information advertised with the forwarding address. Right. From what I remember, the ND-based option was a bit complicated, but if you went in that direction, it would have to be spelled out. Another option was to have a link-local LSA that would map global to link-local addresses, and then install a GA1/128->LA1 route in the RT, which would automatically resolve the lookup for the external. Alex From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 04 14:25:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kP4-0001Rt-W7 for ospf-archive@megatron.ietf.org; Thu, 04 Aug 2005 14:25:15 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28023 for ; Thu, 4 Aug 2005 14:25:13 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010BEC92@cherry.ease.lsoft.com>; Thu, 4 Aug 2005 14:25:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81427583 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Aug 2005 14:25:10 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 4 Aug 2005 14:25:10 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2005 11:25:09 -0700 X-IronPort-AV: i="3.95,168,1120460400"; d="scan'208"; a="329079758:sNHT33257000" Received: from [128.107.134.5] (naiming-linux.cisco.com [128.107.134.5]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j74IP50J006693 for ; Thu, 4 Aug 2005 11:25:05 -0700 (PDT) User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1288871029.20050804055849@psg.com> <42F2145D.8020205@cisco.com> <42F21920.1040301@cisco.com> <571507541.20050804063839@psg.com> <42F21DD3.9010102@cisco.com> <5410120267.20050804103819@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42F25D82.4020303@cisco.com> Date: Thu, 4 Aug 2005 11:25:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: OSPFv3 fwd'ing address To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <5410120267.20050804103819@psg.com> Precedence: list Content-Transfer-Encoding: 7bit Alex Zinin said the following on 08/04/2005 10:38 AM: >>Ok - let's say R3 is in a different routing domain and R1's OSPFv3 does >>go through some measure (possibly extraordinary) to determine a valid >>global address for R3's associated interface and assure the address is >>associated with a global prefix advertised internal to OSPFv3. R2 would >>also have to determine the prefix is directly connected (a route lookup) >>and then go to neighbor discovery to map the global address to the >>link-local address. I can thnk of other solutions but they would require >>more information advertised with the forwarding address. > > > Right. From what I remember, the ND-based option was a bit complicated, > but if you went in that direction, it would have to be spelled out. > Another option was to have a link-local LSA that would map global to > link-local addresses, and then install a GA1/128->LA1 route in the RT, > which would automatically resolve the lookup for the external. > Assume on the shared media there is no OSPF neighbor with the nexthop, there will be no link-local LSAs. ND interaction would be the most reliable way to solve this, and remember link-local address can also change at anytime(thus the relation needs to be callback notification or constant polling). But if we think of this problem in another way, this 'nexthop' is only an internal state within the router, what does anyone care if I use a true 'link-local' address as a nexthop, or use the global address as the nexthop which passed by the OSPF forwarding address? I would not implement the IPv6 forwarding in a way to only accept the link-local as nexthops. thanks. - Naiming > Alex From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 04 14:58:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kvS-00008u-9m for ospf-archive@megatron.ietf.org; Thu, 04 Aug 2005 14:58:44 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29599 for ; Thu, 4 Aug 2005 14:58:40 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010BEC28@cherry.ease.lsoft.com>; Thu, 4 Aug 2005 14:58:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81429821 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Aug 2005 14:58:35 -0400 Received: from 32.97.110.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 4 Aug 2005 14:58:35 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j74IwYWY069334 for ; Thu, 4 Aug 2005 14:58:34 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j74Iwh5q168798 for ; Thu, 4 Aug 2005 12:58:43 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j74IwY0s025386 for ; Thu, 4 Aug 2005 12:58:34 -0600 Received: from [9.17.195.144] (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j74IwYkg025381 for ; Thu, 4 Aug 2005 12:58:34 -0600 MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 08/04/2005 02:58:08 PM, Serialize by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 08/04/2005 02:58:08 PM, Serialize complete at 08/04/2005 02:58:08 PM, S/MIME Sign failed at 08/04/2005 02:58:08 PM: The cryptographic key was not found, S/MIME Sign by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 08/04/2005 02:59:25 PM, Serialize by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 08/04/2005 02:59:25 PM, Serialize complete at 08/04/2005 02:59:25 PM, S/MIME Sign failed at 08/04/2005 02:59:25 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V70_M6_06302005 Beta 4|June 30, 2005) at 08/04/2005 12:58:46, Serialize complete at 08/04/2005 12:58:46 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Content-Type: multipart/alternative; boundary="=_alternative 0068512885257053_=" Message-ID: Date: Thu, 4 Aug 2005 12:58:42 -0600 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: OSPFv3 fwd'ing address To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42F25D82.4020303@cisco.com> Precedence: list This is a multipart message in MIME format. --=_alternative 0068512885257053_= Content-Type: text/plain; charset="US-ASCII" Naiming Shen wrote: > But if we think of this problem in another way, this 'nexthop' is only > an internal state within the router, what does anyone care if > I use a true 'link-local' address as a nexthop, or use the global > address as the nexthop which passed by the OSPF forwarding address? > I would not implement the IPv6 forwarding in a way to only > accept the link-local as nexthops. That's how we implemented it. For the AS-External forwarding address, our implementation will accept any non-link-local address that is reachable using the OSPF protocol. As a user of an AS-External LSA we will send packets for the external destination to the specified forwarding address (if provided) and we assumed others would do the same, so as long as routers in the AS can route to that forwarding address, it should work. This significantly limits its usefulness, but it does work. The place we expect to see this used the most is for external default routes. On our platform the user can specify that an ASBR is to advertise an external default route, and the user can optionally specify a forwarding address to use on that route, with the restrictions that it can't be a link-local address and it has to be an address or prefix that is routable in the OSPF domain. Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA --=_alternative 0068512885257053_= Content-Type: text/html; charset="US-ASCII"
Naiming Shen wrote:

> But if we think of this problem in another way, this 'nexthop' is only
> an internal state within the router, what does anyone care if
> I use a true 'link-local' address as a nexthop, or use the global
> address as the nexthop which passed by the OSPF forwarding address?
> I would not implement the IPv6 forwarding in a way to only
> accept the link-local as nexthops.

That's how we implemented it.  For the AS-External forwarding address, our implementation will accept any non-link-local address that is reachable using the OSPF protocol.  As a user of an AS-External LSA we will send packets for the external destination to the specified forwarding address (if provided) and we assumed others would do the same, so as long as routers in the AS can route to that forwarding address, it should work.

This significantly limits its usefulness, but it does work.  The place we expect to see this used the most is for external default routes.  On our platform the user can specify that an ASBR is to advertise an external default route, and the user can optionally specify a forwarding address to use on that route, with the restrictions that it can't be a link-local address and it has to be an address or prefix that is routable in the OSPF domain.

Mike
-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA --=_alternative 0068512885257053_=-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 06 10:42:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Psm-00088c-WE for ospf-archive@megatron.ietf.org; Sat, 06 Aug 2005 10:42:41 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26579 for ; Sat, 6 Aug 2005 10:42:38 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010C1110@cherry.ease.lsoft.com>; Sat, 6 Aug 2005 10:42:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81626804 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 6 Aug 2005 10:42:37 -0400 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 6 Aug 2005 10:42:36 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j76EgUpU004683 for ; Sat, 6 Aug 2005 15:42:34 +0100 X-X-Sender: paul@sheen.jakma.org References: Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-ID: Date: Sat, 6 Aug 2005 15:42:29 +0100 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: OSPFv3 fwd'ing address To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Hi, On Thu, 4 Aug 2005, Mike Fox wrote: > specify a forwarding address to use on that route, with the > restrictions that it can't be a link-local address and it has to be > an address or prefix that is routable in the OSPF domain. Which seem like quite reasonable restrictions really. And definitely far more reasonable than mandating the sucking up of details of global->LL address resolution and/or neighbour discovery into OSPF. > Mike regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "All the people are so happy now, their heads are caving in. I'm glad they are a snowman with protective rubber skin" -- They Might Be Giants From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 06 11:52:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Qxv-0005OC-Vo for ospf-archive@megatron.ietf.org; Sat, 06 Aug 2005 11:52:04 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28744 for ; Sat, 6 Aug 2005 11:52:01 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010C1071@cherry.ease.lsoft.com>; Sat, 6 Aug 2005 11:52:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81629390 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 6 Aug 2005 11:52:00 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 6 Aug 2005 11:52:00 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 06 Aug 2005 08:52:00 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,172,1120460400"; d="scan'208"; a="4955462:sNHT21496740" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j76FpvT6009097 for ; Sat, 6 Aug 2005 11:51:57 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 11:52:07 -0400 Received: from [10.86.242.179] ([10.86.242.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 11:51:43 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1288871029.20050804055849@psg.com> <42F2145D.8020205@cisco.com> <42F21920.1040301@cisco.com> <571507541.20050804063839@psg.com> <42F21DD3.9010102@cisco.com> <5410120267.20050804103819@psg.com> <42F25D82.4020303@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2005 15:51:43.0600 (UTC) FILETIME=[BE2C1F00:01C59A9E] Message-ID: <42F4ABC6.1060107@cisco.com> Date: Sat, 6 Aug 2005 08:23:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 fwd'ing address To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42F25D82.4020303@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Naiming, This is precisely why I didn't want to go down this path. Thanks for articulating all the complexities. Acee Naiming Shen wrote: > Alex Zinin said the following on 08/04/2005 10:38 AM: > >>> Ok - let's say R3 is in a different routing domain and R1's OSPFv3 does >>> go through some measure (possibly extraordinary) to determine a valid >>> global address for R3's associated interface and assure the address is >>> associated with a global prefix advertised internal to OSPFv3. R2 would >>> also have to determine the prefix is directly connected (a route >>> lookup) >>> and then go to neighbor discovery to map the global address to the >>> link-local address. I can thnk of other solutions but they would >>> require >>> more information advertised with the forwarding address. >> >> >> >> Right. From what I remember, the ND-based option was a bit complicated, >> but if you went in that direction, it would have to be spelled out. >> Another option was to have a link-local LSA that would map global to >> link-local addresses, and then install a GA1/128->LA1 route in the RT, >> which would automatically resolve the lookup for the external. >> > > Assume on the shared media there is no OSPF neighbor with the nexthop, > there will be no link-local LSAs. ND interaction would be the most > reliable way to solve this, and remember link-local address can > also change at anytime(thus the relation needs to be callback > notification or constant polling). > > But if we think of this problem in another way, this 'nexthop' is only > an internal state within the router, what does anyone care if > I use a true 'link-local' address as a nexthop, or use the global > address as the nexthop which passed by the OSPF forwarding address? > I would not implement the IPv6 forwarding in a way to only > accept the link-local as nexthops. > > thanks. > - Naiming > > >> Alex > > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 06 11:52:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Qxx-0005Ob-9B for ospf-archive@megatron.ietf.org; Sat, 06 Aug 2005 11:52:05 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28747 for ; Sat, 6 Aug 2005 11:52:02 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010C10CD@cherry.ease.lsoft.com>; Sat, 6 Aug 2005 11:52:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81629401 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 6 Aug 2005 11:52:02 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 6 Aug 2005 11:52:02 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 06 Aug 2005 11:52:02 -0400 X-IronPort-AV: i="3.95,172,1120449600"; d="scan'208"; a="65494288:sNHT30407520" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j76FpvT8009097 for ; Sat, 6 Aug 2005 11:51:59 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 11:52:08 -0400 Received: from [10.86.242.179] ([10.86.242.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 11:51:58 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2005 15:51:58.0459 (UTC) FILETIME=[C7076CB0:01C59A9E] Message-ID: <42F4AD6B.4090207@cisco.com> Date: Sat, 6 Aug 2005 08:30:35 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 fwd'ing address To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Mike, Mike Fox wrote: >Naiming Shen wrote: > > > >>But if we think of this problem in another way, this 'nexthop' is only >>an internal state within the router, what does anyone care if >>I use a true 'link-local' address as a nexthop, or use the global >>address as the nexthop which passed by the OSPF forwarding address? >>I would not implement the IPv6 forwarding in a way to only >>accept the link-local as nexthops. >> >> > >That's how we implemented it. For the AS-External forwarding address, our >implementation will accept any non-link-local address that is reachable >using the OSPF protocol. As a user of an AS-External LSA we will send >packets for the external destination to the specified forwarding address >(if provided) and we assumed others would do the same, so as long as >routers in the AS can route to that forwarding address, it should work. > >This significantly limits its usefulness, but it does work. The place we >expect to see this used the most is for external default routes. On our >platform the user can specify that an ASBR is to advertise an external >default route, and the user can optionally specify a forwarding address to >use on that route, with the restrictions that it can't be a link-local >address and it has to be an address or prefix that is routable in the OSPF >domain. > > I don't see any problems with this as long as a global IPv6 address is available - either as the next-hop gateway in the redistributed route or explicitly specified. I could document this case. . >Mike >----------------------------------------------------------------------- >Enterprise Network Solutions >----------------------------------------------------------------------- >Research Triangle Park, NC USA > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 09 04:34:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2PZI-0003jn-Dq for ospf-archive@megatron.ietf.org; Tue, 09 Aug 2005 04:34:40 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22122 for ; Tue, 9 Aug 2005 04:34:38 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010C5954@cherry.ease.lsoft.com>; Tue, 9 Aug 2005 4:34:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81901903 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Aug 2005 04:34:33 -0400 Received: from 147.234.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 9 Aug 2005 04:34:33 -0400 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 08/09/2005 11:40:26 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Tue, 9 Aug 2005 11:34:30 +0300 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: Recommended OSPFv2 TEQ To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Which test equipment is best for testing OSPFv2 application (IXIA, Spirenet Smartbits, Agilent N2X, etc. )? Thanks, Ilan From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Thu Aug 11 17:03:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3KCg-0003Ce-Qk for ospf-archive@megatron.ietf.org; Thu, 11 Aug 2005 17:03:08 -0400 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 RAA27340 for ; Thu, 11 Aug 2005 17:03:02 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <15.0058DAB5@grape.ease.lsoft.com>; Thu, 11 Aug 2005 17:03:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82184902 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Aug 2005 17:03:03 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 11 Aug 2005 17:03:02 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2005 17:03:02 -0400 X-IronPort-AV: i="3.96,100,1122868800"; d="scan'208"; a="66205013:sNHT30817424" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7BL2pTE005993 for ; Thu, 11 Aug 2005 17:03:00 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 17:02:59 -0400 Received: from [10.82.240.205] ([10.82.240.205]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 17:02:59 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <42778DFC.4060107@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 11 Aug 2005 21:02:59.0678 (UTC) FILETIME=[0E0C37E0:01C59EB8] Message-ID: <42FBBD03.6090004@cisco.com> Date: Thu, 11 Aug 2005 17:02:59 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42778DFC.4060107@cisco.com> Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA27340 At the 63rd IETF in Paris, I proposed that we remove the restriction on t= he flooding of unknown LSAs into stub areas. Here is an excerpt from the=20 presentation: - Section 2.9 mandates that an OSPFv3 router should NOT advertise an unknown LSA if the U bit is set to =931=94 =96 flood as if known. ->Should be removed in RFC 2740 respin. ->Limits backward compatibility for new LSA types ->No corresponding rule for opaque LSAs ->Fact that LSA is flooded at all implies one router is stub/NSSA=20 understands it. ->Ineffective/non-deterministic database limit ->As long as there is an intra-area spanning tree of routers that understand the LSA type - The LSA will be in everyones database Comments? Speak now if you wish to retain the current stub area restricti= on. My intent is to deprecate it with an appendix documenting it's removal. Thanks, Acee Acee Lindem wrote: > In the evolution of the OSPFv2 protocol specification > (RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous > bugs were fixed and some protocol behaviors were altered. Examples > include the metric cost for area ranges and the selection of the > ASBR for AS external route computation. > > In the context of documenting the OSPFv3 NSSA differences I've > looked again at section 2.10 and I really think the idea of not floodin= g > unknown LSA types with the U-bit set to 1 is broken. I think it breaks > the whole idea of being able to introduce new LSA types in a backward > compatible fashion. Furthermore, it won't stop the leakage of these > unknown LSAs when some routers understand them and others do not - > it all depends on whether you have a spanning tree of routers that > understand them. Since the LSAs in question are area scoped or link > scoped, it implies that at least one router (the originator)=20 > understands the > new type and you will have a mixture. IMHO, this is broken. I've had > some discussions with others who agree. At this juncture, > we have 3 alternatives: > > 1) Remove the restriction for that unknown LSAs with the U-bit > set to 0 for stub areas. > 2) Extend the broken restriction to NSSAs in the update. > 3) Limit the damage to stub areas and only restrict AS scoped LSAs > from NSSAs. > > Of course, I'd vote for #1 or I wouldn't be sending this E-mail. > > Thanks, > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 11 20:13:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3NB9-0002MI-6k for ospf-archive@megatron.ietf.org; Thu, 11 Aug 2005 20:13:43 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07891 for ; Thu, 11 Aug 2005 20:13:41 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010C890F@cherry.ease.lsoft.com>; Thu, 11 Aug 2005 20:13:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82216229 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Aug 2005 20:13:37 -0400 Received: from 207.69.195.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 11 Aug 2005 20:13:37 -0400 Received: from h-68-164-89-195.snvacaid.dynamic.covad.net ([68.164.89.195] helo=earthlink.net) by pop-gadwall.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1E3NB2-0002vk-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Aug 2005 20:13:37 -0400 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: <42778DFC.4060107@cisco.com> <42FBBD03.6090004@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Message-ID: <42FBE8A5.916FCADE@earthlink.net> Date: Thu, 11 Aug 2005 17:09:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA07891 Group, I vote NOT to remove the restriction on the flooding of unknown LSAs into stub area. I vote for #2 or #3. Sorry, I have not spent any major time looking at the pros / cons between the later 2. Why? 1) The primary reason is that some of the these LSAs are unknown to a percentage of the routers within the stub area. Even the "attempt" to limit them would follow the reason to limit the database size, memory requirements, sizing of OSPF control packets, etc... This limit is suggested in the 1st paragraph of every OSPF v2 RFC. A copy is in the middle of this email. 2) What is an unknown LSA? What LSA type greater than X is an unknown? What help is it by having just 1 router understand it? Can they equal in number over time External-LSAs and be totally useless in our env? Where should we put the older routers that we want to isolate from our network? 3) Is is possible to have 30% - 90% of LSAs in a router's db be present in a stub area, be unknown LSAs? Shouldn't their be an attempt to limit this percentage? 3b) Could we be using / spending a large percentage of our OSPF control packet time / resources handling unknown LSAs? 4) Backward compatibility.. I would assume that most environments would not like to just start seeing something new in their network just show up. "An area can be configured as a stub when there is a single exit point from the area, or when the choice of exit point need not be made on a per-external-destination basis." Lets look at the third word, can. It would be different if we used the word SHOULD or MUST. Thus, if a area that CAN be configured as a stub wishes to process unknown LSAs, then why not configure the without the STUB area identification? Wouldn't this allow for backward capability? Yes, we then allow AS-external-LSAs in this non named stubby area. Or create a new "stubby area" type that accepts or not accept, xyz type LSAs. This new area type would then be allowed to accept new LSAs as they show up? The diff would be that "unknown LSAs" have no restrictions and could consume the majority of the router's LSDB. Mitchell Erblich ----------------------- RFC 1247, 1583, 2178, 2328 : OSPFv2. --------- 3.6 Supporting stub areas In some Autonomous Systems, the majority of the topological database may consist of external advertisements. An OSPF external advertisement is usually flooded throughout the entire AS. However, OSPF allows certain areas to be configured as "stub areas". External advertisements are not flooded into/throughout stub areas; routing to AS external destinations in these areas is based on a (per-area) default only. This reduces the topological database size, and therefore the memory requirements, for a stub area's internal routers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Acee Lindem wrote: >=20 > At the 63rd IETF in Paris, I proposed that we remove the restriction on= the > flooding of unknown LSAs into stub areas. Here is an excerpt from the > presentation: >=20 > - Section 2.9 mandates that an OSPFv3 router should NOT advertise an > unknown LSA if the U bit is set to =931=94 =96 flood as if known. > ->Should be removed in RFC 2740 respin. > ->Limits backward compatibility for new LSA types > ->No corresponding rule for opaque LSAs > ->Fact that LSA is flooded at all implies one router is stub/NSSA > understands it. > ->Ineffective/non-deterministic database limit > ->As long as there is an intra-area spanning tree of routers that > understand the LSA type - The LSA will be in everyones database >=20 > Comments? Speak now if you wish to retain the current stub area restric= tion. > My intent is to deprecate it with an appendix documenting it's removal. >=20 > Thanks, > Acee >=20 > Acee Lindem wrote: >=20 > > In the evolution of the OSPFv2 protocol specification > > (RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous > > bugs were fixed and some protocol behaviors were altered. Examples > > include the metric cost for area ranges and the selection of the > > ASBR for AS external route computation. > > > > In the context of documenting the OSPFv3 NSSA differences I've > > looked again at section 2.10 and I really think the idea of not flood= ing > > unknown LSA types with the U-bit set to 1 is broken. I think it break= s > > the whole idea of being able to introduce new LSA types in a backward > > compatible fashion. Furthermore, it won't stop the leakage of these > > unknown LSAs when some routers understand them and others do not - > > it all depends on whether you have a spanning tree of routers that > > understand them. Since the LSAs in question are area scoped or link > > scoped, it implies that at least one router (the originator) > > understands the > > new type and you will have a mixture. IMHO, this is broken. I've had > > some discussions with others who agree. At this juncture, > > we have 3 alternatives: > > > > 1) Remove the restriction for that unknown LSAs with the U-bit > > set to 0 for stub areas. > > 2) Extend the broken restriction to NSSAs in the update. > > 3) Limit the damage to stub areas and only restrict AS scoped LSAs > > from NSSAs. > > > > Of course, I'd vote for #1 or I wouldn't be sending this E-mail. > > > > Thanks, > > Acee > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 11 22:33:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3PMk-0006fd-Ru for ospf-archive@megatron.ietf.org; Thu, 11 Aug 2005 22:33:50 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13594 for ; Thu, 11 Aug 2005 22:33:48 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010C8A1C@cherry.ease.lsoft.com>; Thu, 11 Aug 2005 22:33:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82224445 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Aug 2005 22:33:44 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 11 Aug 2005 22:33:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7C2Xh979184 for ; Thu, 11 Aug 2005 19:33:43 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7C2XcG72385 for ; Thu, 11 Aug 2005 19:33:38 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v733) References: <42778DFC.4060107@cisco.com> <42FBBD03.6090004@cisco.com> <42FBE8A5.916FCADE@earthlink.net> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.733) Message-ID: Date: Thu, 11 Aug 2005 19:33:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42FBE8A5.916FCADE@earthlink.net> Precedence: list Content-Transfer-Encoding: quoted-printable I guess the broader question is, does this really matter at all? Are =20= stub areas even useful any longer? Once upon a time, routers were memory-starved little boxes, but it's =20 not clear to me at this point why anybody actually needs stub areas, =20 unless they're still running AGS+'s someplace. Stub areas were a hack 15+ years ago (along with a bunch of other =20 sort-sighted optimizations) but they don't seem all that useful these =20= days... --Dave On Aug 11, 2005, at 5:09 PM, Erblichs wrote: > Group, > > I vote NOT to remove the restriction on the > flooding of unknown LSAs into stub area. I vote for > #2 or #3. Sorry, I have not spent any major time looking > at the pros / cons between the later 2. > > Why? > 1) The primary reason is that some of the these LSAs > are unknown to a percentage of the routers within > the stub area. Even the "attempt" to limit them > would follow the reason to limit the database size, > memory requirements, sizing of OSPF control packets, > etc... This limit is suggested in the 1st paragraph > of every OSPF v2 RFC. A copy is in the middle of this > email. > > 2) What is an unknown LSA? What LSA type greater than > X is an unknown? What help is it by having just 1 > router understand it? Can they equal in number > over time External-LSAs and be totally useless in > our env? Where should we put the older routers that > we want to isolate from our network? > > 3) Is is possible to have 30% - 90% of LSAs in a router's > db be present in a stub area, be unknown LSAs? Shouldn't > their be an attempt to limit this percentage? > > 3b) Could we be using / spending a large percentage > of our OSPF control packet time / resources > handling unknown LSAs? > > 4) Backward compatibility.. I would assume that most > environments would not like to just start seeing > something new in their network just show up. > > "An area can be configured as a stub when there is a single exit > point from the area, or when the choice of exit point need not > be made on a per-external-destination basis." > > Lets look at the third word, can. It would be different > if we used the word SHOULD or MUST. > > Thus, if a area that CAN be configured as a stub wishes > to process unknown LSAs, then why not configure the > without the STUB area identification? Wouldn't this allow > for backward capability? Yes, we then allow AS-external-LSAs > in this non named stubby area. > > Or create a new "stubby area" type that accepts or > not accept, xyz type LSAs. This new area type would then be > allowed to accept new LSAs as they show up? The diff > would be that "unknown LSAs" have no restrictions and > could consume the majority of the router's LSDB. > > > Mitchell Erblich > ----------------------- > > > RFC 1247, 1583, 2178, 2328 : OSPFv2. > --------- > 3.6 Supporting stub areas > > In some Autonomous Systems, the majority of the topological =20 > database may > consist of external advertisements. An OSPF external advertisement is > usually flooded throughout the entire AS. However, OSPF allows =20 > certain > areas to be configured as "stub areas". External advertisements =20 > are not > flooded into/throughout stub areas; routing to AS external =20 > destinations > in these areas is based on a (per-area) default only. This reduces =20= > the > topological database size, and therefore the memory requirements, =20 > for a > stub area's internal routers. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > Acee Lindem wrote: > >> >> At the 63rd IETF in Paris, I proposed that we remove the =20 >> restriction on the >> flooding of unknown LSAs into stub areas. Here is an excerpt from the >> presentation: >> >> - Section 2.9 mandates that an OSPFv3 router should NOT advertise an >> unknown LSA if the U bit is set to =931=94 =96 flood as if known. >> ->Should be removed in RFC 2740 respin. >> ->Limits backward compatibility for new LSA types >> ->No corresponding rule for opaque LSAs >> ->Fact that LSA is flooded at all implies one router is stub/NSSA >> understands it. >> ->Ineffective/non-deterministic database limit >> ->As long as there is an intra-area spanning tree of routers that >> understand the LSA type - The LSA will be in everyones database >> >> Comments? Speak now if you wish to retain the current stub area =20 >> restriction. >> My intent is to deprecate it with an appendix documenting it's =20 >> removal. >> >> Thanks, >> Acee >> >> Acee Lindem wrote: >> >> >>> In the evolution of the OSPFv2 protocol specification >>> (RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous >>> bugs were fixed and some protocol behaviors were altered. Examples >>> include the metric cost for area ranges and the selection of the >>> ASBR for AS external route computation. >>> >>> In the context of documenting the OSPFv3 NSSA differences I've >>> looked again at section 2.10 and I really think the idea of not =20 >>> flooding >>> unknown LSA types with the U-bit set to 1 is broken. I think it =20 >>> breaks >>> the whole idea of being able to introduce new LSA types in a =20 >>> backward >>> compatible fashion. Furthermore, it won't stop the leakage of these >>> unknown LSAs when some routers understand them and others do not - >>> it all depends on whether you have a spanning tree of routers that >>> understand them. Since the LSAs in question are area scoped or link >>> scoped, it implies that at least one router (the originator) >>> understands the >>> new type and you will have a mixture. IMHO, this is broken. I've had >>> some discussions with others who agree. At this juncture, >>> we have 3 alternatives: >>> >>> 1) Remove the restriction for that unknown LSAs with the U-bit >>> set to 0 for stub areas. >>> 2) Extend the broken restriction to NSSAs in the update. >>> 3) Limit the damage to stub areas and only restrict AS scoped LSAs >>> from NSSAs. >>> >>> Of course, I'd vote for #1 or I wouldn't be sending this E-mail. >>> >>> Thanks, >>> Acee >>> >>> > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 12 09:24:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZWh-000753-4E for ospf-archive@megatron.ietf.org; Fri, 12 Aug 2005 09:24:47 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21487 for ; Fri, 12 Aug 2005 09:24:44 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010C92A4@cherry.ease.lsoft.com>; Fri, 12 Aug 2005 9:24:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82294639 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Aug 2005 09:24:42 -0400 Received: from 32.97.110.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 12 Aug 2005 09:24:42 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7CDOgWY219798 for ; Fri, 12 Aug 2005 09:24:42 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7CDOQhh533518 for ; Fri, 12 Aug 2005 07:24:26 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7CDOf2f021318 for ; Fri, 12 Aug 2005 07:24:41 -0600 Received: from [9.17.195.144] (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7CDOfBe021312 for ; Fri, 12 Aug 2005 07:24:41 -0600 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 X-MIMETrack: S/MIME Sign by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 08/12/2005 09:25:39 AM, Serialize by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 08/12/2005 09:25:39 AM, Serialize complete at 08/12/2005 09:25:39 AM, S/MIME Sign failed at 08/12/2005 09:25:39 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V70_M6_06302005 Beta 4|June 30, 2005) at 08/12/2005 07:25:02, Serialize complete at 08/12/2005 07:25:02 Content-Type: multipart/alternative; boundary="=_alternative 0049C29F8525705B_=" Message-ID: Date: Fri, 12 Aug 2005 07:24:59 -0600 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list This is a multipart message in MIME format. --=_alternative 0049C29F8525705B_= Content-Type: text/plain; charset="US-ASCII" Dave Katz wrote: > I guess the broader question is, does this really matter at all? Are > stub areas even useful any longer? Yes and yes!!! > Once upon a time, routers were memory-starved little boxes, but it's > not clear to me at this point why anybody actually needs stub areas, > unless they're still running AGS+'s someplace. Not every box running OSPF is a router. My platform, z/OS, is an example. It is far from a "memory-started little box." However its main purpose is to be an application host but it runs OSPF in support of value-added features like sysplex and dynamic VIPA, and also to optimize failover recovery and interactions with its routers, etc. Our customers often need to run OSPF but they want to devote as few resources to it as they can because they want to spend the cycles running databases, CICS, IMS, and other business applications. For several years we have been recommending that our customers put our boxes into totally stubby areas whenever possible, and have gotten very positive results with that setup. So given the above you may not be surprised to learn that my preference is to NOT allow unknown LSAs (or any additional LSA type) in stub areas. We don't support NSSA on our platform so I don't really have an opinion on what you do with that. Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA --=_alternative 0049C29F8525705B_= Content-Type: text/html; charset="US-ASCII"
Dave Katz wrote:

> I guess the broader question is, does this really matter at all?  Are  
> stub areas even useful any longer?

Yes and yes!!!

> Once upon a time, routers were memory-starved little boxes, but it's  
> not clear to me at this point why anybody actually needs stub areas,  
> unless they're still running AGS+'s someplace.

Not every box running OSPF is a router.  My platform, z/OS, is an example.  It is far from a "memory-started little box." However its main purpose is to be an application host but it runs OSPF in support of value-added features like sysplex and dynamic VIPA, and also to optimize failover recovery and interactions with its routers, etc.  Our customers often need to run OSPF but they want to devote as few resources to it as they can because they want to spend the cycles running databases, CICS, IMS, and other business applications.  For several years we have been recommending that our customers put our boxes into totally stubby areas whenever possible, and have gotten very positive results with that setup.  

So given the above you may not be surprised to learn that my preference is to NOT allow unknown LSAs (or any additional LSA type) in stub areas.  We don't support NSSA on our platform so I don't really have an opinion on what you do with that.

Mike
-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA
--=_alternative 0049C29F8525705B_=-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 12 10:37:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3aej-0000gE-NY for ospf-archive@megatron.ietf.org; Fri, 12 Aug 2005 10:37:09 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28121 for ; Fri, 12 Aug 2005 10:37:06 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010C93D6@cherry.ease.lsoft.com>; Fri, 12 Aug 2005 10:37:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82301876 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Aug 2005 10:37:02 -0400 Received: from 47.129.242.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 12 Aug 2005 10:37:00 -0400 Received: from zrtphxm0.corp.nortel.com (zrtphxm0.corp.nortel.com [47.140.202.49]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7CEZ0K27053 for ; Fri, 12 Aug 2005 10:35:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: RFC 2370 Update and a Proposed Change to Stub Area Behavior Thread-Index: AcWe5kbdUOci1rm9RhawPmUJdUX2bQAXtGhw Message-ID: Date: Fri, 12 Aug 2005 10:36:37 -0400 Reply-To: Mailing List Sender: Mailing List From: Andrew Smith Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Stub areas are very useful. Some networks, such as cable modem networks, branch out from the core of the network like tree roots. Some providers choose to run OSPF on the Layer 3 CMTSs which may or may not be able to handle thousands of routes. I have used Stub and NSSA areas in these situations with very good results. The routers and CMTSs are quite peaceful with only a few hundred intra-area routes. Unless you have a network full of high-end routers I recommend using Stub or NSSA areas on segments of the network that don't require a full routing table or a full view of the routing domain. It can increase operational stability of the network. Regards, Andy Smith -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave Katz Sent: Thursday, August 11, 2005 10:34 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior I guess the broader question is, does this really matter at all? Are =20 stub areas even useful any longer? Once upon a time, routers were memory-starved little boxes, but it's =20 not clear to me at this point why anybody actually needs stub areas, =20 unless they're still running AGS+'s someplace. Stub areas were a hack 15+ years ago (along with a bunch of other =20 sort-sighted optimizations) but they don't seem all that useful these =20 days... --Dave On Aug 11, 2005, at 5:09 PM, Erblichs wrote: > Group, > > I vote NOT to remove the restriction on the > flooding of unknown LSAs into stub area. I vote for > #2 or #3. Sorry, I have not spent any major time looking > at the pros / cons between the later 2. > > Why? > 1) The primary reason is that some of the these LSAs > are unknown to a percentage of the routers within > the stub area. Even the "attempt" to limit them > would follow the reason to limit the database size, > memory requirements, sizing of OSPF control packets, > etc... This limit is suggested in the 1st paragraph > of every OSPF v2 RFC. A copy is in the middle of this > email. > > 2) What is an unknown LSA? What LSA type greater than > X is an unknown? What help is it by having just 1 > router understand it? Can they equal in number > over time External-LSAs and be totally useless in > our env? Where should we put the older routers that > we want to isolate from our network? > > 3) Is is possible to have 30% - 90% of LSAs in a router's > db be present in a stub area, be unknown LSAs? Shouldn't > their be an attempt to limit this percentage? > > 3b) Could we be using / spending a large percentage > of our OSPF control packet time / resources > handling unknown LSAs? > > 4) Backward compatibility.. I would assume that most > environments would not like to just start seeing > something new in their network just show up. > > "An area can be configured as a stub when there is a single exit > point from the area, or when the choice of exit point need not > be made on a per-external-destination basis." > > Lets look at the third word, can. It would be different > if we used the word SHOULD or MUST. > > Thus, if a area that CAN be configured as a stub wishes > to process unknown LSAs, then why not configure the > without the STUB area identification? Wouldn't this allow > for backward capability? Yes, we then allow AS-external-LSAs > in this non named stubby area. > > Or create a new "stubby area" type that accepts or > not accept, xyz type LSAs. This new area type would then be > allowed to accept new LSAs as they show up? The diff > would be that "unknown LSAs" have no restrictions and > could consume the majority of the router's LSDB. > > > Mitchell Erblich > ----------------------- > > > RFC 1247, 1583, 2178, 2328 : OSPFv2. > --------- > 3.6 Supporting stub areas > > In some Autonomous Systems, the majority of the topological > database may > consist of external advertisements. An OSPF external advertisement is > usually flooded throughout the entire AS. However, OSPF allows =20 > certain > areas to be configured as "stub areas". External advertisements =20 > are not > flooded into/throughout stub areas; routing to AS external =20 > destinations > in these areas is based on a (per-area) default only. This reduces =20 > the > topological database size, and therefore the memory requirements, =20 > for a > stub area's internal routers. > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Acee Lindem wrote: > >> >> At the 63rd IETF in Paris, I proposed that we remove the =20 >> restriction on the >> flooding of unknown LSAs into stub areas. Here is an excerpt from the >> presentation: >> >> - Section 2.9 mandates that an OSPFv3 router should NOT advertise an >> unknown LSA if the U bit is set to "1" - flood as if known. >> ->Should be removed in RFC 2740 respin. >> ->Limits backward compatibility for new LSA types >> ->No corresponding rule for opaque LSAs >> ->Fact that LSA is flooded at all implies one router is stub/NSSA >> understands it. >> ->Ineffective/non-deterministic database limit >> ->As long as there is an intra-area spanning tree of routers that >> understand the LSA type - The LSA will be in everyones database >> >> Comments? Speak now if you wish to retain the current stub area =20 >> restriction. >> My intent is to deprecate it with an appendix documenting it's =20 >> removal. >> >> Thanks, >> Acee >> >> Acee Lindem wrote: >> >> >>> In the evolution of the OSPFv2 protocol specification >>> (RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous >>> bugs were fixed and some protocol behaviors were altered. Examples >>> include the metric cost for area ranges and the selection of the >>> ASBR for AS external route computation. >>> >>> In the context of documenting the OSPFv3 NSSA differences I've >>> looked again at section 2.10 and I really think the idea of not =20 >>> flooding >>> unknown LSA types with the U-bit set to 1 is broken. I think it =20 >>> breaks >>> the whole idea of being able to introduce new LSA types in a =20 >>> backward >>> compatible fashion. Furthermore, it won't stop the leakage of these >>> unknown LSAs when some routers understand them and others do not - >>> it all depends on whether you have a spanning tree of routers that >>> understand them. Since the LSAs in question are area scoped or link >>> scoped, it implies that at least one router (the originator) >>> understands the >>> new type and you will have a mixture. IMHO, this is broken. I've had >>> some discussions with others who agree. At this juncture, >>> we have 3 alternatives: >>> >>> 1) Remove the restriction for that unknown LSAs with the U-bit >>> set to 0 for stub areas. >>> 2) Extend the broken restriction to NSSAs in the update. >>> 3) Limit the damage to stub areas and only restrict AS scoped LSAs >>> from NSSAs. >>> >>> Of course, I'd vote for #1 or I wouldn't be sending this E-mail. >>> >>> Thanks, >>> Acee >>> >>> > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 12 11:42:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bfj-0004uD-GL for ospf-archive@megatron.ietf.org; Fri, 12 Aug 2005 11:42:15 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01850 for ; Fri, 12 Aug 2005 11:42:11 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010C9515@cherry.ease.lsoft.com>; Fri, 12 Aug 2005 11:42:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82306907 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Aug 2005 11:42:09 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 12 Aug 2005 11:42:09 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 12 Aug 2005 08:42:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="5759949:sNHT23743620" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7CFfmTO017964 for ; Fri, 12 Aug 2005 11:42:07 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:42:05 -0400 Received: from [64.102.198.240] ([64.102.198.240]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:42:05 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <42778DFC.4060107@cisco.com> <42FBBD03.6090004@cisco.com> <42FBE8A5.916FCADE@earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 12 Aug 2005 15:42:05.0332 (UTC) FILETIME=[63F9ED40:01C59F54] Message-ID: <42FCC34D.6020702@cisco.com> Date: Fri, 12 Aug 2005 11:42:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42FBE8A5.916FCADE@earthlink.net> Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA01850 Hi Mitchell, Thanks for reponding - I was hoping someone would initiate some=20 discussion (the ADs always ask whether a change was discussed on the mailing list :^). Anyway, what I'm proposing is no worse that OSPFv2. Consider the=20 following points: - The unknown LSA types in question are link or area scoped. Hence, this implies that at least one router in the stub or NSSA area=20 understands them (at least one would hope an implementation would not originate an LSA it didn= 't understand :^). - The OSPFv2 analogy is a link or area scoped opaque LSA with unknown typ= e. There is no such restriction for these LSAs in OSPFv2 stub or NSSA areas. - The mechanism is topology dependent. As long as there is a spanning=20 tree of OSPFv3 routers in the stub or NSSA understanding the LSA type, it will be flooded to all routers in the area. If there is a real requirement to=20 limit the flooding domain, customers and vendors will implement filters which will deterministically limit flooding. - Experience has shown that the introducion of new OSPFv3 LSA types is extremely slow. Hence, I don't see the need to limit the flooding to limi= t database size (if there a need, see the previous point). Thanks, Acee Erblichs wrote: >Group, > > I vote NOT to remove the restriction on the >flooding of unknown LSAs into stub area. I vote for >#2 or #3. Sorry, I have not spent any major time looking >at the pros / cons between the later 2. > >Why? > 1) The primary reason is that some of the these LSAs > are unknown to a percentage of the routers within > the stub area. Even the "attempt" to limit them > would follow the reason to limit the database size, > memory requirements, sizing of OSPF control packets, > etc... This limit is suggested in the 1st paragraph > of every OSPF v2 RFC. A copy is in the middle of this > email. > > 2) What is an unknown LSA? What LSA type greater than > X is an unknown? What help is it by having just 1 > router understand it? Can they equal in number > over time External-LSAs and be totally useless in > our env? Where should we put the older routers that > we want to isolate from our network? > > 3) Is is possible to have 30% - 90% of LSAs in a router's > db be present in a stub area, be unknown LSAs? Shouldn't > their be an attempt to limit this percentage? > > 3b) Could we be using / spending a large percentage > of our OSPF control packet time / resources > handling unknown LSAs? > > 4) Backward compatibility.. I would assume that most > environments would not like to just start seeing > something new in their network just show up. > > "An area can be configured as a stub when there is a single exit > point from the area, or when the choice of exit point need not > be made on a per-external-destination basis." > > Lets look at the third word, can. It would be different > if we used the word SHOULD or MUST. > > Thus, if a area that CAN be configured as a stub wishes > to process unknown LSAs, then why not configure the > without the STUB area identification? Wouldn't this allow > for backward capability? Yes, we then allow AS-external-LSAs > in this non named stubby area. > > Or create a new "stubby area" type that accepts or > not accept, xyz type LSAs. This new area type would then be > allowed to accept new LSAs as they show up? The diff > would be that "unknown LSAs" have no restrictions and > could consume the majority of the router's LSDB. > > > Mitchell Erblich > ----------------------- > > >RFC 1247, 1583, 2178, 2328 : OSPFv2. >--------- >3.6 Supporting stub areas > >In some Autonomous Systems, the majority of the topological database may >consist of external advertisements. An OSPF external advertisement is >usually flooded throughout the entire AS. However, OSPF allows certain >areas to be configured as "stub areas". External advertisements are not >flooded into/throughout stub areas; routing to AS external destinations >in these areas is based on a (per-area) default only. This reduces the >topological database size, and therefore the memory requirements, for a >stub area's internal routers. > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Acee Lindem wrote: > =20 > >>At the 63rd IETF in Paris, I proposed that we remove the restriction on= the >>flooding of unknown LSAs into stub areas. Here is an excerpt from the >>presentation: >> >>- Section 2.9 mandates that an OSPFv3 router should NOT advertise an >>unknown LSA if the U bit is set to =931=94 =96 flood as if known. >>->Should be removed in RFC 2740 respin. >>->Limits backward compatibility for new LSA types >>->No corresponding rule for opaque LSAs >>->Fact that LSA is flooded at all implies one router is stub/NSSA >>understands it. >>->Ineffective/non-deterministic database limit >>->As long as there is an intra-area spanning tree of routers that >>understand the LSA type - The LSA will be in everyones database >> >>Comments? Speak now if you wish to retain the current stub area restric= tion. >>My intent is to deprecate it with an appendix documenting it's removal. >> >>Thanks, >>Acee >> >>Acee Lindem wrote: >> >> =20 >> >>>In the evolution of the OSPFv2 protocol specification >>>(RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous >>>bugs were fixed and some protocol behaviors were altered. Examples >>>include the metric cost for area ranges and the selection of the >>>ASBR for AS external route computation. >>> >>>In the context of documenting the OSPFv3 NSSA differences I've >>>looked again at section 2.10 and I really think the idea of not floodi= ng >>>unknown LSA types with the U-bit set to 1 is broken. I think it breaks >>>the whole idea of being able to introduce new LSA types in a backward >>>compatible fashion. Furthermore, it won't stop the leakage of these >>>unknown LSAs when some routers understand them and others do not - >>>it all depends on whether you have a spanning tree of routers that >>>understand them. Since the LSAs in question are area scoped or link >>>scoped, it implies that at least one router (the originator) >>>understands the >>>new type and you will have a mixture. IMHO, this is broken. I've had >>>some discussions with others who agree. At this juncture, >>>we have 3 alternatives: >>> >>>1) Remove the restriction for that unknown LSAs with the U-bit >>>set to 0 for stub areas. >>>2) Extend the broken restriction to NSSAs in the update. >>>3) Limit the damage to stub areas and only restrict AS scoped LSAs >>>from NSSAs. >>> >>>Of course, I'd vote for #1 or I wouldn't be sending this E-mail. >>> >>>Thanks, >>>Acee >>> >>> =20 >>> > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 12 11:50:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bnw-0007so-Ev for ospf-archive@megatron.ietf.org; Fri, 12 Aug 2005 11:50:44 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02222 for ; Fri, 12 Aug 2005 11:50:40 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010C96B6@cherry.ease.lsoft.com>; Fri, 12 Aug 2005 11:50:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82308117 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Aug 2005 11:50:39 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 12 Aug 2005 11:50:38 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 12 Aug 2005 08:50:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="5761296:sNHT24347092" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7CFoBTU020329 for ; Fri, 12 Aug 2005 11:50:36 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:50:10 -0400 Received: from [64.102.198.240] ([64.102.198.240]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:50:10 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Aug 2005 15:50:10.0507 (UTC) FILETIME=[8529C1B0:01C59F55] Message-ID: <42FCC532.60304@cisco.com> Date: Fri, 12 Aug 2005 11:50:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit I'd have to agree that stub and NSSA areas are still beneficial. Even if all of the routers in the routing domain could accommodate all the LSAs, there is still a benefit in being able break up the routing domain into smaller areas with reduced flooding and simplified routing. NSSAs have additional benefits in being able to partition (with limitations) your routing domain into sub-domains sharing a common backbone (a la Pat Murphy's network). Thanks, Acee Andrew Smith wrote: >Stub areas are very useful. Some networks, such as cable modem networks, >branch out from the core of the network like tree roots. Some providers >choose to run OSPF on the Layer 3 CMTSs which may or may not be able to >handle thousands of routes. > >I have used Stub and NSSA areas in these situations with very good >results. The routers and CMTSs are quite peaceful with only a few >hundred intra-area routes. > >Unless you have a network full of high-end routers I recommend using >Stub or NSSA areas on segments of the network that don't require a full >routing table or a full view of the routing domain. It can increase >operational stability of the network. > >Regards, >Andy Smith > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave >Katz >Sent: Thursday, August 11, 2005 10:34 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior > > >I guess the broader question is, does this really matter at all? Are >stub areas even useful any longer? > >Once upon a time, routers were memory-starved little boxes, but it's >not clear to me at this point why anybody actually needs stub areas, >unless they're still running AGS+'s someplace. > >Stub areas were a hack 15+ years ago (along with a bunch of other >sort-sighted optimizations) but they don't seem all that useful these >days... > >--Dave > > >On Aug 11, 2005, at 5:09 PM, Erblichs wrote: > > > >>Group, >> >> I vote NOT to remove the restriction on the >>flooding of unknown LSAs into stub area. I vote for >>#2 or #3. Sorry, I have not spent any major time looking >>at the pros / cons between the later 2. >> >>Why? >> 1) The primary reason is that some of the these LSAs >> are unknown to a percentage of the routers within >> the stub area. Even the "attempt" to limit them >> would follow the reason to limit the database size, >> memory requirements, sizing of OSPF control packets, >> etc... This limit is suggested in the 1st paragraph >> of every OSPF v2 RFC. A copy is in the middle of this >> email. >> >> 2) What is an unknown LSA? What LSA type greater than >> X is an unknown? What help is it by having just 1 >> router understand it? Can they equal in number >> over time External-LSAs and be totally useless in >> our env? Where should we put the older routers that >> we want to isolate from our network? >> >> 3) Is is possible to have 30% - 90% of LSAs in a router's >> db be present in a stub area, be unknown LSAs? Shouldn't >> their be an attempt to limit this percentage? >> >> 3b) Could we be using / spending a large percentage >> of our OSPF control packet time / resources >> handling unknown LSAs? >> >> 4) Backward compatibility.. I would assume that most >> environments would not like to just start seeing >> something new in their network just show up. >> >> "An area can be configured as a stub when there is a single exit >> point from the area, or when the choice of exit point need not >> be made on a per-external-destination basis." >> >> Lets look at the third word, can. It would be different >> if we used the word SHOULD or MUST. >> >> Thus, if a area that CAN be configured as a stub wishes >> to process unknown LSAs, then why not configure the >> without the STUB area identification? Wouldn't this allow >> for backward capability? Yes, we then allow AS-external-LSAs >> in this non named stubby area. >> >> Or create a new "stubby area" type that accepts or >> not accept, xyz type LSAs. This new area type would then be >> allowed to accept new LSAs as they show up? The diff >> would be that "unknown LSAs" have no restrictions and >> could consume the majority of the router's LSDB. >> >> >> Mitchell Erblich >> ----------------------- >> >> >>RFC 1247, 1583, 2178, 2328 : OSPFv2. >>--------- >>3.6 Supporting stub areas >> >>In some Autonomous Systems, the majority of the topological >>database may >>consist of external advertisements. An OSPF external advertisement is >>usually flooded throughout the entire AS. However, OSPF allows >>certain >>areas to be configured as "stub areas". External advertisements >>are not >>flooded into/throughout stub areas; routing to AS external >>destinations >>in these areas is based on a (per-area) default only. This reduces >>the >>topological database size, and therefore the memory requirements, >>for a >>stub area's internal routers. >> >> >>========================== >> >>======================== >> >>Acee Lindem wrote: >> >> >> >>>At the 63rd IETF in Paris, I proposed that we remove the >>>restriction on the >>>flooding of unknown LSAs into stub areas. Here is an excerpt from the >>>presentation: >>> >>>- Section 2.9 mandates that an OSPFv3 router should NOT advertise an >>>unknown LSA if the U bit is set to "1" - flood as if known. >>>->Should be removed in RFC 2740 respin. >>>->Limits backward compatibility for new LSA types >>>->No corresponding rule for opaque LSAs >>>->Fact that LSA is flooded at all implies one router is stub/NSSA >>>understands it. >>>->Ineffective/non-deterministic database limit >>>->As long as there is an intra-area spanning tree of routers that >>>understand the LSA type - The LSA will be in everyones database >>> >>>Comments? Speak now if you wish to retain the current stub area >>>restriction. >>>My intent is to deprecate it with an appendix documenting it's >>>removal. >>> >>>Thanks, >>>Acee >>> >>>Acee Lindem wrote: >>> >>> >>> >>> >>>>In the evolution of the OSPFv2 protocol specification >>>>(RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous >>>>bugs were fixed and some protocol behaviors were altered. Examples >>>>include the metric cost for area ranges and the selection of the >>>>ASBR for AS external route computation. >>>> >>>>In the context of documenting the OSPFv3 NSSA differences I've >>>>looked again at section 2.10 and I really think the idea of not >>>>flooding >>>>unknown LSA types with the U-bit set to 1 is broken. I think it >>>>breaks >>>>the whole idea of being able to introduce new LSA types in a >>>>backward >>>>compatible fashion. Furthermore, it won't stop the leakage of these >>>>unknown LSAs when some routers understand them and others do not - >>>>it all depends on whether you have a spanning tree of routers that >>>>understand them. Since the LSAs in question are area scoped or link >>>>scoped, it implies that at least one router (the originator) >>>>understands the >>>>new type and you will have a mixture. IMHO, this is broken. I've had >>>>some discussions with others who agree. At this juncture, >>>>we have 3 alternatives: >>>> >>>>1) Remove the restriction for that unknown LSAs with the U-bit >>>>set to 0 for stub areas. >>>>2) Extend the broken restriction to NSSAs in the update. >>>>3) Limit the damage to stub areas and only restrict AS scoped LSAs >>>>from NSSAs. >>>> >>>>Of course, I'd vote for #1 or I wouldn't be sending this E-mail. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 12 16:00:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3fhQ-0003kS-1a for ospf-archive@megatron.ietf.org; Fri, 12 Aug 2005 16:00:16 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16637 for ; Fri, 12 Aug 2005 16:00:09 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010C9923@cherry.ease.lsoft.com>; Fri, 12 Aug 2005 16:00:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82333790 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Aug 2005 16:00:02 -0400 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 12 Aug 2005 15:50:01 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E3fXW-0004Fe-5r; Fri, 12 Aug 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Fri, 12 Aug 2005 15:50:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-05.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF for IPv6 Author(s) : D. Ferguson, et al. Filename : draft-ietf-ospf-ospfv3-update-05.txt Pages : 95 Date : 2005-8-12 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload. Even with larger IPv6 packet, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-update-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-12114000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-update-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-12114000.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 12 22:37:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ltg-00048x-MB for ospf-archive@megatron.ietf.org; Fri, 12 Aug 2005 22:37:20 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16281 for ; Fri, 12 Aug 2005 22:37:17 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010C9D65@cherry.ease.lsoft.com>; Fri, 12 Aug 2005 22:37:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82352853 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Aug 2005 22:37:10 -0400 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 12 Aug 2005 22:37:10 -0400 Received: from h-68-164-89-195.snvacaid.dynamic.covad.net ([68.164.89.195] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1E3ltW-00017Q-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Aug 2005 22:37:10 -0400 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: <42778DFC.4060107@cisco.com> <42FBBD03.6090004@cisco.com> <42FBE8A5.916FCADE@earthlink.net> <42FCC34D.6020702@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Message-ID: <42FD5A65.206D25B7@earthlink.net> Date: Fri, 12 Aug 2005 19:26:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA16281 Acee, Yes, I understand your points, however... If ONLY one router understands the new type, I don't see the benefit of "fully accepting" the new type into stub areas. What prevents a SIGNIFICANT FLOOD of specialized=20 unknown types? =09 Even if a small percentage of routers in the area understands these unknown types, what do we gain? It would make sense if we had a notifcation type message that could be generated to reject these unknown types. I thought the reasoning for specialized areas was to generate a homogeneous handing of message types. Unknown types to some routers in the area violates this. If we don't explicitly state acceptance criteria for unknown types for stub area then it is a defacto-standard that we have this restriction. Wouldn't changing this value promote heterogeneous handling of unknown types? Murphy says, by the time unknown type A becomes generally supported, we will have introduced unknown type B.. > >>->As long as there is an intra-area spanning tree of routers that > >>understand the LSA type - The LSA will be in everyones database > >> Ok, then why not add a mechanism for filtering these unknowns from the LSDBs?=20 > >>->No corresponding rule for opaque LSAs Should we then add a defacto-standard rule? Mitchell Erblich -------------------- =09 Acee Lindem wrote: >=20 > Hi Mitchell, > Thanks for reponding - I was hoping someone would initiate some > discussion (the > ADs always ask whether a change was discussed on the mailing list :^). > Anyway, what I'm proposing is no worse that OSPFv2. Consider the > following points: >=20 > - The unknown LSA types in question are link or area scoped. Hence, > this implies that at least one router in the stub or NSSA area > understands them (at > least one would hope an implementation would not originate an LSA it di= dn't > understand :^). > - The OSPFv2 analogy is a link or area scoped opaque LSA with unknown t= ype. > There is no such restriction for these LSAs in OSPFv2 stub or NSSA area= s. > - The mechanism is topology dependent. As long as there is a spanning > tree of > OSPFv3 routers in the stub or NSSA understanding the LSA type, it will = be > flooded to all routers in the area. If there is a real requirement to > limit the > flooding domain, customers and vendors will implement filters which wil= l > deterministically limit flooding. > - Experience has shown that the introducion of new OSPFv3 LSA types is > extremely slow. Hence, I don't see the need to limit the flooding to li= mit > database size (if there a need, see the previous point). >=20 > Thanks, > Acee >=20 > Erblichs wrote: >=20 > >Group, > > > > I vote NOT to remove the restriction on the > >flooding of unknown LSAs into stub area. I vote for > >#2 or #3. Sorry, I have not spent any major time looking > >at the pros / cons between the later 2. > > > >Why? > > 1) The primary reason is that some of the these LSAs > > are unknown to a percentage of the routers within > > the stub area. Even the "attempt" to limit them > > would follow the reason to limit the database size, > > memory requirements, sizing of OSPF control packets, > > etc... This limit is suggested in the 1st paragraph > > of every OSPF v2 RFC. A copy is in the middle of this > > email. > > > > 2) What is an unknown LSA? What LSA type greater than > > X is an unknown? What help is it by having just 1 > > router understand it? Can they equal in number > > over time External-LSAs and be totally useless in > > our env? Where should we put the older routers that > > we want to isolate from our network? > > > > 3) Is is possible to have 30% - 90% of LSAs in a router's > > db be present in a stub area, be unknown LSAs? Shouldn't > > their be an attempt to limit this percentage? > > > > 3b) Could we be using / spending a large percentage > > of our OSPF control packet time / resources > > handling unknown LSAs? > > > > 4) Backward compatibility.. I would assume that most > > environments would not like to just start seeing > > something new in their network just show up. > > > > "An area can be configured as a stub when there is a single exi= t > > point from the area, or when the choice of exit point need not > > be made on a per-external-destination basis." > > > > Lets look at the third word, can. It would be different > > if we used the word SHOULD or MUST. > > > > Thus, if a area that CAN be configured as a stub wishes > > to process unknown LSAs, then why not configure the > > without the STUB area identification? Wouldn't this allow > > for backward capability? Yes, we then allow AS-external-LSAs > > in this non named stubby area. > > > > Or create a new "stubby area" type that accepts or > > not accept, xyz type LSAs. This new area type would then be > > allowed to accept new LSAs as they show up? The diff > > would be that "unknown LSAs" have no restrictions and > > could consume the majority of the router's LSDB. > > > > > > Mitchell Erblich > > ----------------------- > > > > > >RFC 1247, 1583, 2178, 2328 : OSPFv2. > >--------- > >3.6 Supporting stub areas > > > >In some Autonomous Systems, the majority of the topological database m= ay > >consist of external advertisements. An OSPF external advertisement is > >usually flooded throughout the entire AS. However, OSPF allows certai= n > >areas to be configured as "stub areas". External advertisements are n= ot > >flooded into/throughout stub areas; routing to AS external destination= s > >in these areas is based on a (per-area) default only. This reduces th= e > >topological database size, and therefore the memory requirements, for = a > >stub area's internal routers. > > > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Acee Lindem wrote: > > > > > >>At the 63rd IETF in Paris, I proposed that we remove the restriction = on the > >>flooding of unknown LSAs into stub areas. Here is an excerpt from the > >>presentation: > >> > >>- Section 2.9 mandates that an OSPFv3 router should NOT advertise an > >>unknown LSA if the U bit is set to =931=94 =96 flood as if known. > >>->Should be removed in RFC 2740 respin. > >>->Limits backward compatibility for new LSA types > >>->No corresponding rule for opaque LSAs > >>->Fact that LSA is flooded at all implies one router is stub/NSSA > >>understands it. > >>->Ineffective/non-deterministic database limit > >>->As long as there is an intra-area spanning tree of routers that > >>understand the LSA type - The LSA will be in everyones database > >> > >>Comments? Speak now if you wish to retain the current stub area restr= iction. > >>My intent is to deprecate it with an appendix documenting it's remova= l. > >> > >>Thanks, > >>Acee > >> > >>Acee Lindem wrote: > >> > >> > >> > >>>In the evolution of the OSPFv2 protocol specification > >>>(RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous > >>>bugs were fixed and some protocol behaviors were altered. Examples > >>>include the metric cost for area ranges and the selection of the > >>>ASBR for AS external route computation. > >>> > >>>In the context of documenting the OSPFv3 NSSA differences I've > >>>looked again at section 2.10 and I really think the idea of not floo= ding > >>>unknown LSA types with the U-bit set to 1 is broken. I think it brea= ks > >>>the whole idea of being able to introduce new LSA types in a backwar= d > >>>compatible fashion. Furthermore, it won't stop the leakage of these > >>>unknown LSAs when some routers understand them and others do not - > >>>it all depends on whether you have a spanning tree of routers that > >>>understand them. Since the LSAs in question are area scoped or link > >>>scoped, it implies that at least one router (the originator) > >>>understands the > >>>new type and you will have a mixture. IMHO, this is broken. I've had > >>>some discussions with others who agree. At this juncture, > >>>we have 3 alternatives: > >>> > >>>1) Remove the restriction for that unknown LSAs with the U-bit > >>>set to 0 for stub areas. > >>>2) Extend the broken restriction to NSSAs in the update. > >>>3) Limit the damage to stub areas and only restrict AS scoped LSAs > >>>from NSSAs. > >>> > >>>Of course, I'd vote for #1 or I wouldn't be sending this E-mail. > >>> > >>>Thanks, > >>>Acee > >>> > >>> > >>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Aug 14 20:29:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4SrL-00059O-48 for ospf-archive@megatron.ietf.org; Sun, 14 Aug 2005 20:29:47 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20701 for ; Sun, 14 Aug 2005 20:29:44 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010CB682@cherry.ease.lsoft.com>; 14 Aug 2005 20:29:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82527258 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 14 Aug 2005 20:29:42 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 14 Aug 2005 20:29:41 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Aug 2005 17:29:41 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7F0Ta0J005709 for ; Sun, 14 Aug 2005 17:29:36 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 14 Aug 2005 20:29:38 -0400 Received: from [10.82.217.200] ([10.82.217.200]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 14 Aug 2005 20:29:37 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <42778DFC.4060107@cisco.com> <42FBBD03.6090004@cisco.com> <42FBE8A5.916FCADE@earthlink.net> <42FCC34D.6020702@cisco.com> <42FD5A65.206D25B7@earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 15 Aug 2005 00:29:37.0705 (UTC) FILETIME=[6B164190:01C5A130] Message-ID: <42FFE1F1.10906@cisco.com> Date: Sun, 14 Aug 2005 20:29:37 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42FD5A65.206D25B7@earthlink.net> Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA20701 Mitchell, Although we are in complete disagreement, this debate is good. I encourage others to chime in. See my responses inline. Erblichs wrote: >Acee, > > Yes, I understand your points, however... > > If ONLY one router understands the new type, > I don't see the benefit of "fully accepting" > the new type into stub areas. > > What prevents a SIGNIFICANT FLOOD of specialized=20 > unknown types? > =20 > If the one router that understands the new LSA type is connected to all t= he other routers in the stub or NSSA - then the LSA is in everyone's databas= e anyway. It isn't as if these LSAs are coming from some distance galaxy th= ey are in the stub or NSSA area in question and are presumably under a singl= e administrative control. >=09 > Even if a small percentage of routers in the area > understands these unknown types, what do we gain? > =20 > Simplicity and deterministic behavior. Also, it could ease migration if=20 the application of the new LSA isn't dependent on all routers in the area understanding i= t. > It would make sense if we had a notifcation type > message that could be generated to reject these > unknown types. > =20 > I certainly wouldn't want to go there. This defeats the whole purpose of=20 OSPFv3 unknown type handling. > I thought the reasoning for specialized areas was > to generate a homogeneous handing of message > types. Unknown types to some routers in the area > violates this. > > If we don't explicitly state acceptance criteria > for unknown types for stub area then it is a > defacto-standard that we have this restriction. > Wouldn't changing this value promote heterogeneous > handling of unknown types? Murphy says, by the time > unknown type A becomes generally supported, we > will have introduced unknown type B.. > > =20 > >>>>->As long as there is an intra-area spanning tree of routers that >>>>understand the LSA type - The LSA will be in everyones database >>>> >>>> =20 >>>> > Ok, then why not add a mechanism for filtering these > unknowns from the LSDBs?=20 > =20 > Filtering techniques have been implemented. They would be difficult to=20 standardize since they break some basic OSPF principles (e.g., routers within an=20 area have an identical database). >>>>->No corresponding rule for opaque LSAs >>>> =20 >>>> > > Should we then add a defacto-standard rule? > =20 > De facto?? This implies that it is already being used. In fact, the oppos= ite is true - RFC 2370 has been a PS document since July 1998 (and an=20 implemented draft for years long) and I've never heard of anyone having a requirement= to prevent unknown opaque types from being flooded in stub/NSSA areas. > Mitchell Erblich > -------------------- > >=09 >Acee Lindem wrote: > =20 > >>Hi Mitchell, >>Thanks for reponding - I was hoping someone would initiate some >>discussion (the >>ADs always ask whether a change was discussed on the mailing list :^). >>Anyway, what I'm proposing is no worse that OSPFv2. Consider the >>following points: >> >>- The unknown LSA types in question are link or area scoped. Hence, >>this implies that at least one router in the stub or NSSA area >>understands them (at >>least one would hope an implementation would not originate an LSA it di= dn't >>understand :^). >>- The OSPFv2 analogy is a link or area scoped opaque LSA with unknown t= ype. >>There is no such restriction for these LSAs in OSPFv2 stub or NSSA area= s. >>- The mechanism is topology dependent. As long as there is a spanning >>tree of >>OSPFv3 routers in the stub or NSSA understanding the LSA type, it will = be >>flooded to all routers in the area. If there is a real requirement to >>limit the >>flooding domain, customers and vendors will implement filters which wil= l >>deterministically limit flooding. >>- Experience has shown that the introducion of new OSPFv3 LSA types is >>extremely slow. Hence, I don't see the need to limit the flooding to li= mit >>database size (if there a need, see the previous point). >> >>Thanks, >>Acee >> >>Erblichs wrote: >> >> =20 >> >>>Group, >>> >>> I vote NOT to remove the restriction on the >>>flooding of unknown LSAs into stub area. I vote for >>>#2 or #3. Sorry, I have not spent any major time looking >>>at the pros / cons between the later 2. >>> >>>Why? >>> 1) The primary reason is that some of the these LSAs >>> are unknown to a percentage of the routers within >>> the stub area. Even the "attempt" to limit them >>> would follow the reason to limit the database size, >>> memory requirements, sizing of OSPF control packets, >>> etc... This limit is suggested in the 1st paragraph >>> of every OSPF v2 RFC. A copy is in the middle of this >>> email. >>> >>> 2) What is an unknown LSA? What LSA type greater than >>> X is an unknown? What help is it by having just 1 >>> router understand it? Can they equal in number >>> over time External-LSAs and be totally useless in >>> our env? Where should we put the older routers that >>> we want to isolate from our network? >>> >>> 3) Is is possible to have 30% - 90% of LSAs in a router's >>> db be present in a stub area, be unknown LSAs? Shouldn't >>> their be an attempt to limit this percentage? >>> >>> 3b) Could we be using / spending a large percentage >>> of our OSPF control packet time / resources >>> handling unknown LSAs? >>> >>> 4) Backward compatibility.. I would assume that most >>> environments would not like to just start seeing >>> something new in their network just show up. >>> >>> "An area can be configured as a stub when there is a single exit >>> point from the area, or when the choice of exit point need not >>> be made on a per-external-destination basis." >>> >>> Lets look at the third word, can. It would be different >>> if we used the word SHOULD or MUST. >>> >>> Thus, if a area that CAN be configured as a stub wishes >>> to process unknown LSAs, then why not configure the >>> without the STUB area identification? Wouldn't this allow >>> for backward capability? Yes, we then allow AS-external-LSAs >>> in this non named stubby area. >>> >>> Or create a new "stubby area" type that accepts or >>> not accept, xyz type LSAs. This new area type would then be >>> allowed to accept new LSAs as they show up? The diff >>> would be that "unknown LSAs" have no restrictions and >>> could consume the majority of the router's LSDB. >>> >>> >>> Mitchell Erblich >>> ----------------------- >>> >>> >>>RFC 1247, 1583, 2178, 2328 : OSPFv2. >>>--------- >>>3.6 Supporting stub areas >>> >>>In some Autonomous Systems, the majority of the topological database m= ay >>>consist of external advertisements. An OSPF external advertisement is >>>usually flooded throughout the entire AS. However, OSPF allows certai= n >>>areas to be configured as "stub areas". External advertisements are n= ot >>>flooded into/throughout stub areas; routing to AS external destination= s >>>in these areas is based on a (per-area) default only. This reduces th= e >>>topological database size, and therefore the memory requirements, for = a >>>stub area's internal routers. >>> >>> >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>> >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>>Acee Lindem wrote: >>> >>> >>> =20 >>> >>>>At the 63rd IETF in Paris, I proposed that we remove the restriction = on the >>>>flooding of unknown LSAs into stub areas. Here is an excerpt from the >>>>presentation: >>>> >>>>- Section 2.9 mandates that an OSPFv3 router should NOT advertise an >>>>unknown LSA if the U bit is set to =931=94 =96 flood as if known. >>>>->Should be removed in RFC 2740 respin. >>>>->Limits backward compatibility for new LSA types >>>>->No corresponding rule for opaque LSAs >>>>->Fact that LSA is flooded at all implies one router is stub/NSSA >>>>understands it. >>>>->Ineffective/non-deterministic database limit >>>>->As long as there is an intra-area spanning tree of routers that >>>>understand the LSA type - The LSA will be in everyones database >>>> >>>>Comments? Speak now if you wish to retain the current stub area restr= iction. >>>>My intent is to deprecate it with an appendix documenting it's remova= l. >>>> >>>>Thanks, >>>>Acee >>>> >>>>Acee Lindem wrote: >>>> >>>> >>>> >>>> =20 >>>> >>>>>In the evolution of the OSPFv2 protocol specification >>>>>(RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous >>>>>bugs were fixed and some protocol behaviors were altered. Examples >>>>>include the metric cost for area ranges and the selection of the >>>>>ASBR for AS external route computation. >>>>> >>>>>In the context of documenting the OSPFv3 NSSA differences I've >>>>>looked again at section 2.10 and I really think the idea of not floo= ding >>>>>unknown LSA types with the U-bit set to 1 is broken. I think it brea= ks >>>>>the whole idea of being able to introduce new LSA types in a backwar= d >>>>>compatible fashion. Furthermore, it won't stop the leakage of these >>>>>unknown LSAs when some routers understand them and others do not - >>>>>it all depends on whether you have a spanning tree of routers that >>>>>understand them. Since the LSAs in question are area scoped or link >>>>>scoped, it implies that at least one router (the originator) >>>>>understands the >>>>>new type and you will have a mixture. IMHO, this is broken. I've had >>>>>some discussions with others who agree. At this juncture, >>>>>we have 3 alternatives: >>>>> >>>>>1) Remove the restriction for that unknown LSAs with the U-bit >>>>>set to 0 for stub areas. >>>>>2) Extend the broken restriction to NSSAs in the update. >>>>>3) Limit the damage to stub areas and only restrict AS scoped LSAs >>>>> =20 >>>>> >>>>>from NSSAs. >>>> =20 >>>> >>>>>Of course, I'd vote for #1 or I wouldn't be sending this E-mail. >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>> >>> =20 >>> > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 15 02:01:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Y2D-0002t1-IJ for ospf-archive@megatron.ietf.org; Mon, 15 Aug 2005 02:01:21 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02869 for ; Mon, 15 Aug 2005 02:01:17 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010CBBF8@cherry.ease.lsoft.com>; Mon, 15 Aug 2005 2:01:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82539716 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Aug 2005 02:01:11 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 15 Aug 2005 02:01:09 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 14 Aug 2005 23:01:10 -0700 X-IronPort-AV: i="3.96,106,1122879600"; d="scan'208"; a="204807240:sNHT31436776" Received: from smirtorawxp (sjc-vpn5-69.cisco.com [10.21.88.69]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7F6162i019151 for ; Sun, 14 Aug 2005 23:01:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWfsAZg5yccN0oZRsuNTyWREqEslgBqVaUw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: <200508150601.j7F6162i019151@sj-core-4.cisco.com> Date: Sun, 14 Aug 2005 23:01:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42FD5A65.206D25B7@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Mitchell, If an application requires an area flooding scope, typically its LSA will have the U-bit set so that the LSA be flooded as if it was understood and avoiding the requirement that all routers understand the new LSA. With the current specification in 2740, we cannot define new LSA with area flooding scope for Stub / NSSA unless the U-bit is clear therefore this cause two issues - We cannot have incremental deployment for a given application - We would be defining two LS type for the same application as U-bit will be set for regular areas and U-bit will be clear for Stub/ NSSA where all routers have to understand the new LSA Obviously this is broken. As already mentioned, in OSPFv2 new opaque LSA are flooded in Stub / NSSA therefore there is no reason trying to prevent that in OSPFv3.... Sina -> -----Original Message----- -> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On -> Behalf Of Erblichs -> Sent: Friday, August 12, 2005 7:27 PM -> To: OSPF@PEACH.EASE.LSOFT.COM -> Subject: Re: RFC 2370 Update and a Proposed Change to Stub -> Area Behavior -> -> Acee, -> -> Yes, I understand your points, however... -> -> If ONLY one router understands the new type, -> I don't see the benefit of "fully accepting" -> the new type into stub areas. -> -> What prevents a SIGNIFICANT FLOOD of specialized -> unknown types? -> -> Even if a small percentage of routers in the area -> understands these unknown types, what do we gain? -> -> It would make sense if we had a notifcation type -> message that could be generated to reject these -> unknown types. -> -> I thought the reasoning for specialized areas was -> to generate a homogeneous handing of message -> types. Unknown types to some routers in the area -> violates this. -> -> If we don't explicitly state acceptance criteria -> for unknown types for stub area then it is a -> defacto-standard that we have this restriction. -> Wouldn't changing this value promote heterogeneous -> handling of unknown types? Murphy says, by the time -> unknown type A becomes generally supported, we -> will have introduced unknown type B.. -> -> > >>->As long as there is an intra-area spanning tree of routers that -> > >>understand the LSA type - The LSA will be in everyones database -> > >> -> Ok, then why not add a mechanism for filtering these -> unknowns from the LSDBs? -> -> > >>->No corresponding rule for opaque LSAs -> -> Should we then add a defacto-standard rule? -> -> Mitchell Erblich -> -------------------- -> -> -> Acee Lindem wrote: -> > -> > Hi Mitchell, -> > Thanks for reponding - I was hoping someone would initiate some -> > discussion (the ADs always ask whether a change was -> discussed on the -> > mailing list :^). -> > Anyway, what I'm proposing is no worse that OSPFv2. Consider the -> > following points: -> > -> > - The unknown LSA types in question are link or area -> scoped. Hence, -> > this implies that at least one router in the stub or NSSA area -> > understands them (at least one would hope an -> implementation would not -> > originate an LSA it didn't understand :^). -> > - The OSPFv2 analogy is a link or area scoped opaque LSA -> with unknown type. -> > There is no such restriction for these LSAs in OSPFv2 stub -> or NSSA areas. -> > - The mechanism is topology dependent. As long as there is -> a spanning -> > tree of -> > OSPFv3 routers in the stub or NSSA understanding the LSA -> type, it will -> > be flooded to all routers in the area. If there is a real -> requirement -> > to limit the flooding domain, customers and vendors will implement -> > filters which will deterministically limit flooding. -> > - Experience has shown that the introducion of new OSPFv3 -> LSA types is -> > extremely slow. Hence, I don't see the need to limit the -> flooding to -> > limit database size (if there a need, see the previous point). -> > -> > Thanks, -> > Acee -> > -> > Erblichs wrote: -> > -> > >Group, -> > > -> > > I vote NOT to remove the restriction on the flooding of -> > >unknown LSAs into stub area. I vote for -> > >#2 or #3. Sorry, I have not spent any major time looking -> at the pros -> > >/ cons between the later 2. -> > > -> > >Why? -> > > 1) The primary reason is that some of the these LSAs -> > > are unknown to a percentage of the routers within -> > > the stub area. Even the "attempt" to limit them -> > > would follow the reason to limit the database size, -> > > memory requirements, sizing of OSPF control packets, -> > > etc... This limit is suggested in the 1st paragraph -> > > of every OSPF v2 RFC. A copy is in the middle of this -> > > email. -> > > -> > > 2) What is an unknown LSA? What LSA type greater than -> > > X is an unknown? What help is it by having just 1 -> > > router understand it? Can they equal in number -> > > over time External-LSAs and be totally useless in -> > > our env? Where should we put the older routers that -> > > we want to isolate from our network? -> > > -> > > 3) Is is possible to have 30% - 90% of LSAs in a router's -> > > db be present in a stub area, be unknown LSAs? Shouldn't -> > > their be an attempt to limit this percentage? -> > > -> > > 3b) Could we be using / spending a large percentage -> > > of our OSPF control packet time / resources -> > > handling unknown LSAs? -> > > -> > > 4) Backward compatibility.. I would assume that most -> > > environments would not like to just start seeing -> > > something new in their network just show up. -> > > -> > > "An area can be configured as a stub when there is -> a single exit -> > > point from the area, or when the choice of exit -> point need not -> > > be made on a per-external-destination basis." -> > > -> > > Lets look at the third word, can. It would be different -> > > if we used the word SHOULD or MUST. -> > > -> > > Thus, if a area that CAN be configured as a stub wishes -> > > to process unknown LSAs, then why not configure the -> > > without the STUB area identification? Wouldn't this allow -> > > for backward capability? Yes, we then allow -> AS-external-LSAs -> > > in this non named stubby area. -> > > -> > > Or create a new "stubby area" type that accepts or -> > > not accept, xyz type LSAs. This new area type would then be -> > > allowed to accept new LSAs as they show up? The diff -> > > would be that "unknown LSAs" have no restrictions and -> > > could consume the majority of the router's LSDB. -> > > -> > > -> > > Mitchell Erblich -> > > ----------------------- -> > > -> > > -> > >RFC 1247, 1583, 2178, 2328 : OSPFv2. -> > >--------- -> > >3.6 Supporting stub areas -> > > -> > >In some Autonomous Systems, the majority of the -> topological database -> > >may consist of external advertisements. An OSPF external -> > >advertisement is usually flooded throughout the entire -> AS. However, -> > >OSPF allows certain areas to be configured as "stub -> areas". External -> > >advertisements are not flooded into/throughout stub -> areas; routing to -> > >AS external destinations in these areas is based on a (per-area) -> > >default only. This reduces the topological database size, and -> > >therefore the memory requirements, for a stub area's -> internal routers. -> > > -> > > -> > >========================== -> > > -> > >======================== -> > > -> > >Acee Lindem wrote: -> > > -> > > -> > >>At the 63rd IETF in Paris, I proposed that we remove the -> restriction -> > >>on the flooding of unknown LSAs into stub areas. Here is -> an excerpt -> > >>from the -> > >>presentation: -> > >> -> > >>- Section 2.9 mandates that an OSPFv3 router should NOT -> advertise an -> > >>unknown LSA if the U bit is set to "1" - flood as if known. -> > >>->Should be removed in RFC 2740 respin. -> > >>->Limits backward compatibility for new LSA types No -> corresponding -> > >>->rule for opaque LSAs Fact that LSA is flooded at all -> implies one -> > >>->router is stub/NSSA -> > >>understands it. -> > >>->Ineffective/non-deterministic database limit As long -> as there is -> > >>->an intra-area spanning tree of routers that -> > >>understand the LSA type - The LSA will be in everyones database -> > >> -> > >>Comments? Speak now if you wish to retain the current -> stub area restriction. -> > >>My intent is to deprecate it with an appendix -> documenting it's removal. -> > >> -> > >>Thanks, -> > >>Acee -> > >> -> > >>Acee Lindem wrote: -> > >> -> > >> -> > >> -> > >>>In the evolution of the OSPFv2 protocol specification (RFC -> > >>>1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous bugs -> were fixed -> > >>>and some protocol behaviors were altered. Examples include the -> > >>>metric cost for area ranges and the selection of the -> ASBR for AS -> > >>>external route computation. -> > >>> -> > >>>In the context of documenting the OSPFv3 NSSA differences I've -> > >>>looked again at section 2.10 and I really think the idea of not -> > >>>flooding unknown LSA types with the U-bit set to 1 is broken. I -> > >>>think it breaks the whole idea of being able to -> introduce new LSA -> > >>>types in a backward compatible fashion. Furthermore, it -> won't stop -> > >>>the leakage of these unknown LSAs when some routers -> understand them -> > >>>and others do not - it all depends on whether you have -> a spanning -> > >>>tree of routers that understand them. Since the LSAs in -> question -> > >>>are area scoped or link scoped, it implies that at -> least one router -> > >>>(the originator) understands the new type and you will have a -> > >>>mixture. IMHO, this is broken. I've had some discussions with -> > >>>others who agree. At this juncture, we have 3 alternatives: -> > >>> -> > >>>1) Remove the restriction for that unknown LSAs with -> the U-bit set -> > >>>to 0 for stub areas. -> > >>>2) Extend the broken restriction to NSSAs in the update. -> > >>>3) Limit the damage to stub areas and only restrict AS -> scoped LSAs -> > >>>from NSSAs. -> > >>> -> > >>>Of course, I'd vote for #1 or I wouldn't be sending this E-mail. -> > >>> -> > >>>Thanks, -> > >>>Acee -> > >>> -> > >>> -> > >>> -> > > -> > > -> > > -> From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 15 10:35:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4g3W-0000ha-1Z for ospf-archive@megatron.ietf.org; Mon, 15 Aug 2005 10:35:14 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06497 for ; Mon, 15 Aug 2005 10:35:03 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010CC17C@cherry.ease.lsoft.com>; Mon, 15 Aug 2005 10:21:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82605539 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Aug 2005 10:19:58 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 15 Aug 2005 10:19:57 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2005 10:19:55 -0400 X-IronPort-AV: i="3.96,107,1122868800"; d="txt'?scan'208"; a="66509816:sNHT40835076" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7FEJkQr001805 for ; Mon, 15 Aug 2005 10:19:53 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 10:19:51 -0400 Received: from [10.82.241.69] ([10.82.241.69]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 10:19:51 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000409030006050508090108" X-OriginalArrivalTime: 15 Aug 2005 14:19:51.0410 (UTC) FILETIME=[665E6D20:01C5A1A4] Message-ID: <4300A486.5000001@cisco.com> Date: Mon, 15 Aug 2005 10:19:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF WG Minutes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------000409030006050508090108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached are the minutes from the Paris OSPF WG meeting. Thanks to Dimitri for taking them. Acee --------------000409030006050508090108 Content-Type: text/plain; name="minutes.txt" Content-Disposition: inline; filename="minutes.txt" Content-Transfer-Encoding: 7bit Open Shortest Path First WG (ospf) - Scribe: Dimitri Papadimitriou Wednesday, August 3 at 1030-1230 ================================ CHAIRS: Rohit Dube Acee Lindem AGENDA: o Administriva 5 minutes - Mailing list: OSPF@PEACH.EASE.LSOFT.COM Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 - Scribe? - Blue Sheets o Document Status 10 minutes Acee o OSPFv3 Update 10 minutes draft-ietf-ospf-ospfv3-update-04.txt Acee o Extensions to OSPFv2 for Advertising Optional 15 minutes Route/Link Attribute - draft-miratorabl-ospf-tag-00.txt Sina Mirtorabi o OSPFv3 Graceful Restart - 10 minutes draft-ietf-ospf-ospfv3-graceful-restart-01.txt Padma Pillay-Esnault o OSPF MANET Design Team Update and Next Steps 20-30 minutes Tom Henderson (Acee presenting) o Issues with existing Cryptographic Protection Methods 15 minutes for Routing Protocols draft-manral-rp-existingcrypto-01 Russ White or Vishwas Manral + Alex MTR Forwarding ----- o) Document status (Acee) Progress achieved since Minneapolis meeting (IETF 62) - RFC 4126 (OSPF Refresh and Flooding Reduction in Stable Topologies) - BCP document on "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance" most implementation do already here tese practices have been documented - Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs (draft-ietf-ospf-2547-dnbit-04.txt): blocking on L3VPN . Alex: Lots of activity here, with the main OSPF draft there were a lot of comments; lots of back and forth with the authors and changes to the document; then bring back in L3VPN + OSPF WG with the perspective to have enough details concerning interoperability - so it is for review . Acee: Invite for review for those familiar with the technology. - OSPFv2 Graceful Restart Implementation Report (draft-ietf-ospf-graceful-impl-report-05.txt) waiting on OSPFv2 MIB (normative reference) . Alex: Does not have to be listed as normative reference . Acee: So going to take it as informative and progress with the document - OSPFv2 Management Information Base (MIB) (draft-ietf-ospf-mib-update-08.txt) - OSPF Multi-Area Adjacency (draft-ietf-ospf-multi-area-adj-03.txt): not standards track because of lack of implementation . Alex: Why is it not implemented ? . Acee: Because nobody intends to implement . Alex: It is not because it does change the protocol ? . Acee: Augmentation but not a change to the protocol - Multi-Topology (MT) Routing in OSPF (draft-ietf-ospf-mt-04.txt) - Extensions to OSPF for Advertising Optional Router Capabilities (draft-ietf-ospf-cap-07.txt): Last version addresses Adrian's comments - Authentication/Confidentiality for OSPFv3 (draft-ietf-ospf-ospfv3-auth-07.txt): Revised I-D needed, before LC new version of the draft - Traffic Engineering Extensions to OSPFv3 (draft-ietf-ospf-ospfv3-traffic-05.txt): Last call hung in CCAMP WG as we are going to do this anyway as the WG is going to satisfy ASON requirements with the extensions; so, we are going to add new sub-TLVs to satisfy these requirements (ASON = TE information to control optical switches) - Advertising a Router's Local Addresses in OSPF TE Extensions (draft-ietf-ospf-te-node-addr-02.txt): Relationship with ASON but pretty done here - IANA Considerations for OSPF (draft-ietf-ospf-iana-01.txt): Useful to have this document in the process and have this as a generic document Draft on the table ------------------ - OSPFv3 (OSPF for IPv6) revision (draft-ietf-ospf-ospfv3-update-04.txt): see below - OSPFv3 Graceful Restart (draft-ietf-ospf-ospfv3-graceful-restart-01.txt) - Management Information Base (MIB) for OSPFv3 (draft-ietf-ospf-ospfv3-mib-09.txt): Trap need to be added - Multi-topology routing in OSPFv3 (draft-ietf-ospf-mt-ospfv3-00.txt) - AF ALT for support of addresses families in OSPFv3: should move forward Pekka Salvoa: a document not product of this WG "Point-to-point operation over LAN in link-state routing protocols" (draft-ietf-isis-igp-p2p-over-lan-05.txt) stuck because normative ref. to IS-IS for IPv6 if we want to have this out of the stack something has to be done like separate document; this is something to consider Acee: This function exists and people do it for years but is there much of a rush to make it a separate document ? ... no Acee: The base spec is implemented for years Alex: Check for having informational reference ----- o) OSPFv3 Update 10 minutes draft-ietf-ospf-ospfv3-update-04.txt Acee Summary: - Work completed . many corrections . remove reference to site local . NSSA support added . multiple interfaces per link clarified . VL/IF ID clarified . Add DN bit - Section 2.9 mandates that an OSPFv3 router should not advertize an unknown LSA if the U bit is set to 1 (flood as if known) into stub area; This should be removed in RFC 2740 re-spin limits backward compatibility . no corresponding rules for opaque LSAs . fact that LSA is flooded implies one router is stub/NSSA understand it . ineffective/non-deterministic protection of the database limit Alex: is there a message to the ML ? Acee: yes, 2 messages but no responses; I think the original intention was an attempt to limit size of the DB but it does not work but as dependent on the topology Alex: Problem with the fwd'ing address ? Acee: Done Alex: There was a problem when mapping the fwd'ding address to the ext-hop address (link-local) Acee: Not using link-local address as a fwd'ding address; The problem has been fixed by not advertising the fwd'ing address except for NSSAs; The reason for doing this is that we do not do anything like that in OSPFv2 Alex: This is not what I mean: when an ASBR advertises an AS-external-LSA with as fwd'ing address the (global) address of a router connected to this ASBR, the calculating router will have to map this address to a link-local address Acee: Which is not advertised Alex: Indeed, but in IPv6, the next-hop must be link-local and you may not have a routing entry to perform this resolution Acee: I do understand the problem but I did not fix it, for NSSA you must have a fwd'ing address Alex: Will continue the discussion on the list ---- o Extensions to OSPFv2 for Advertising Optional 15 minutes Route/Link Attribute - draft-miratorabl-ospf-tag-00.txt Sina Mirtorabi Purpose - carry one or more attribute associated to link/route - appl. admin tags in internal OSPF routes - other applications can define further attributes Router Attributes (RA) Opaque LSA (RA LSA) - LSDB Opaque type of 5 - Attr LS Type (one byte) - Unique ID (two bytes) - TLV (payload is TLV based) Four attributes: - Link attribute - Inter-area route attribute - External route attribute - NSSA External route attribute Link Attribute TLV (LA-TLV) (TLV Type 1) Inter-Area/External Route Attribute TLV (RA-TLV) (TLV Type 2/3/4) Definitions of sub-TLV - Standard TAG sub-TLV: carry one or more Tags (for a route) - Extended TAG sub-TLV: carry one or extended Tags (for a route) - MT-ID sub-LTV: carry attributes corr. to multiple topologies as defined in [MTOSPF] Generation of RA LSA - a router configured to advertise link or route attributes - regeneration only if a change occur in the attribute value - across area boundary, an ABR will generate . area scoped RA LSA . AS scoped RA LSA . unless specified by local policy Backward Compatibility . no issues . ABR should be able to flood correctly unless AS scope RA LSA Ask for WG I-D ... consideration as WG I-D ? Acee: Will send a pointer to the list Acee: The encoding as sub-TLV for the topology is to find rapidly information and this the first case of nested sub-TLV but would be introduced incrementally; Also, the document suggests a partition of the LSA ID field (Attr LS Type + ID) Alex: In this new LSA, is the announced information part of the (original) router LSA ? Sina: Yes you are making a reference to this LSA Alex: So no substitution to the existing type ? Sina: No... but we could - this is why there is no metric field we do not do that for the time being and just do this for the existing LSA Alex: We already have the TE LSA for some equivalent purposes Sina: Usage of this LSA is to associate one of more attributes to routes Alex: What kind of information do you envision as associated to routes ? Sina: TAGs can be associated to routing information for filtering e.g. for fast convergence or situation where you want to carry BGP community information; Also in some situations when using IGP and there is a need to carry BGP attributes transparently Alex: This is similar to the IS-IS discussion ... referring to the VPN attribute information better define a specific attribute for doing this Sina: Here any attribute can be associated to the TAGs Acee: TAGs are used for different purposes and this goes already like this today; it is difficult to get advertisement for TAGs Alex: TAGs are needed (not questioning the reason for TAGs) but if you have a mechanism to automatically do something you want not necessarily to expose this to the operation Acee: Here looking for more flexibility... TLVs do not overload the protocols - People overload protocols. Sina: Carry standard TAGs for NSSAs but they carry single TAG and not multiple so would like to be able to carry more than one tag anyway ----- o) OSPFv3 Graceful Restart - 10 minutes draft-ietf-ospf-ospfv3-graceful-restart-01.txt Padma Pillay-Esnault - Common methodology for OSPFv2 and v3 - OSPFv3 specific considerations - OSPFv3 Grace LSA - Going forward . proposed standard . two implementations exist - Questions ? Acee: This is the document closest for LC as all issues are covered ... so pretty good for PS as well Padma: questions ? ?: Grace LSA would not require usage of the interface ID Padma: There are other LSAs that use the interface ID e.g. TE specific LSA Acee: The network LSA uses the interface ID as the LSID. Editors note: As does the link LSA. ----- o) OSPF MANET Design Team Update and Next Steps 20-30 minutes Tom Henderson (Acee presenting) Evaluation of proposal for using OSPF for IGP in MANET experimental protocol and field trial Brief History - MANET WG Std a set of experimental RFCs - PS: draft-baker-... PS - OSPFv3 rather than OSPFv2 - compatibility with non-wireless OSPFv3 - intra-area extensions only - not focusing on transit network case but should not be precluded - scaling goal is 50-100 nodes on wireless channel - leverage on existing MANET work were possible - use RFC 3668 guidance ... Consensus reached so far: - working on defining a new MANET interface type rather than a MANET area type - focusing first on designing an optimized flooding mechanism for new LSA generations - Focus on two active I-Ds - ... Both drafts focus on selecting more efficient relay node sets RNS for flooding Differences between drafts: - source independent vs source dependent Connected Dominated Set (CDS) - use of hellos or LSA for dissemination of two-hop neighborhood information - differential (incr.) hello implementation - draft-ogier* proposes reduction of adjacencies formed in dense networks Review of optimized flooding draft-chandra* Review of draft-ogier* Design team evaluation software - both drafts have been implemented Simulations conducted by Boeing - Criteria for evaluation - Simulation code and documentation shared with the design team members Both techniques reduce the flooding overhead but OSPF was meant to be robust and not necessarily efficient in terms of adj. flooding, etc. Ogier's reduces an extra step in terms of unnecessary routing adjencies Next steps: - Design team struggle to reach consensus on a single recommended approach - proposed to run one more meeting cycles - boeing to process or release reporting and reference implementations (and simulator) Acee: evaluate the two designs so it would be interesting to look at this Boeing code and I am going to look at it. Acee: any comments ? ---- o) MT Routing Fwd'ing considerations (Alex Zinin) In both ISIS MT and OSPF MT, cases with multiple AF on same interface. In general MT requires separate FIBs and need to map incoming packets to MT/FIBs. Implementations have different demux'ing options such as DSCP or arb. IP field (policy-based) but there is no method which is mandatory so interoperability issue Method works but: . no standard demux method . manual configuration . error prone No intend to say do not implement a specific method but we could have one mechanism to be implemented as the standard something that could be used for this is e.g. a DSCP mapping or something being MPLS based Would like to encourage discussions and drafts Tony Li: seems to be unnecessary ... market will do it Alex: which market ? Tony: the market determines interoperability Alex: so ... is interoperability not necessary in your view ? Tony: Specify how implementations interoperate is not necessary since the market is going to drive what you are going to implement so you may end with something relevant so no need or irrelevant Dave Ward: Nothing to be standardized at the data plane level however something informational around the mapping for topology that would otherwise not form adjacencies - but nothing to standardize at the data plane level as explain usage of DSCP code-points would fall into the problem of standardizing code-points - the best-case scenario: have the flexibility to mark the packets and how operators want to use his Acee: I think the usefulness is going to be difficult - we end up with nice names but impossible to have the ISP to implement what we documented here - so it may potentially generate a lot of work without necessarily standardizing the actual usagex Alex: Would that not be useful ? Acee: I share on Dave's views - some level of information document but this may not be complete Chris Hopps: Agree - Tony has a really good point - the interoperability is going to be determined by the providers and the market(ing) is going to drive the different behavior in terms of forwarding Dave: we are discussing intra-domain (?) Alex: Inter-domain single carrier case is also part of this ... there was a requirement for doing this from the operator side to the vendors Tony: At the IETF, we generally standardize the protocols on the wire not their implementation Alex: So we agree that we disagree Tony: You require a configuration option Alex: This is not resulting from a configuration option - here just mappings - anything that is specific in a protocol can potentially be part of the specification but this is not a protocol specification Tony: protocol specification is about protocol on the wire; take a look at the history of the IETF documents e.g. configuration of stub areas Alex: This is not a good analogy here we are speaking about the consistent forwarding behavior Tony: we do not have documents that are specifying forwarding behavior Alex: you have to be capable to forward on the longest prefix match Tony: this is purely a per-system operation Chris: is this not an operator issue ? ... so, it is not up to the spec to fix bad configuration Alex: Purpose is to make easier to specify a common profile between different implementations Tony: Show hand... more hands showing disagreement Dave: We will never be able to limit to this specific case (inter-vendor case)... so we are going to specify a new specific forwarding behavior but what can be standardized is the correlation and the prevention of mis-configurations that can happen, leading to mis-advertisement of specific prefixes but this is outside of the IGP protocol specification and separated from the forwarding behavior asked here Alex: A, B, C being the possible behaviors (possible mappings) Dave: Yes, we could be marking topology X, Y, Z with an ID with the possible behaviors A, B, C ... but I do not have all the details here ----- Acee: Lots of things that are no in the charter that are going to be added in the charter (Annoncement before everyone sneaks off to lunch). ----- o Issues with existing Cryptographic Protection Methods 15 minutes for Routing Protocols draft-manral-rp-existingcrypto-01 Russ White or Vishwas Manral Discussion: Acee: In practice, for OSPFv2 the sequence numbers are not monotically increasing; Usage of router's clock for cryptographic sequence number generation reduces the chance for replay attacks across restarts. ?: OSPF spec does not say it ... Acee: Graceful Restart document recommends this as one way to avoid saving the sequence numbers in non-volatile storage. Rich Graveman: This is a good document for someone that understand protocol security but don't understand the routing protocol issues and for someone that understand the security aspects it is now possible to work on required security properties for the routing protocol - example: layer violation have big effect on security or issues due to the message length that may have an impact on choice of security mechanism Acee: Please, read this draft and articulate what's missing on the RSPEC list. Russ: In RSPEC this may become an informational document and if requirements come out of this it would be interesting to have discussion about the security implication of some of the protocol choices such as for instance usage of multicast --------------000409030006050508090108-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 15 17:38:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mfR-0006fL-Jv for ospf-archive@megatron.ietf.org; Mon, 15 Aug 2005 17:38:49 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06028 for ; Mon, 15 Aug 2005 17:38:47 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010CCB8E@cherry.ease.lsoft.com>; Mon, 15 Aug 2005 17:38:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82662305 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Aug 2005 17:38:48 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 15 Aug 2005 17:28:48 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2005 17:28:46 -0400 X-IronPort-AV: i="3.96,108,1122868800"; d="scan'208"; a="66577148:sNHT28364948" Received: from russpc (rtp-vpn2-524.cisco.com [10.82.242.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7FLSgT7016482 for ; Mon, 15 Aug 2005 17:28:43 -0400 (EDT) Received: from [10.82.242.12] by russpc (PGP Universal service); Mon, 15 Aug 2005 17:28:44 -0500 X-PGP-Universal: processed; by russpc on Mon, 15 Aug 2005 17:28:44 -0500 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200508150601.j7F6162i019151@sj-core-4.cisco.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <43010905.8070208@cisco.com> Date: Mon, 15 Aug 2005 17:28:37 -0400 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200508150601.j7F6162i019151@sj-core-4.cisco.com> Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First, I'll comment that I believe stub areas are still useful.... > If an application requires an area flooding scope, typically its LSA will > have the U-bit set so that the LSA be flooded as if it was understood and > avoiding the requirement that all routers understand the new LSA. With the > current specification in 2740, we cannot define new LSA with area flooding > scope for Stub / NSSA unless the U-bit is clear therefore this cause two > issues > > - We cannot have incremental deployment for a given application > - We would be defining two LS type for the same application as U-bit will be > set for regular areas and U-bit will be clear for Stub/ NSSA where all > routers have to understand the new LSA Correct. I do see some merit in suggesting that an implemenation MAY filter unknowns at a stub area ABR, as long as the network implementor is willing to accept the possible negative consequences from this action. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQwEJDBEdu7FIVPTkEQK5YQCffvjVDjTfbSjZq/NAxSpqgMG7RfQAoLOK c+Q2GrKYlQwY2zd1P3sfdDqD =hjsk -----END PGP SIGNATURE----- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 15 21:08:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pwh-0006rO-Pf for ospf-archive@megatron.ietf.org; Mon, 15 Aug 2005 21:08:51 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17586 for ; Mon, 15 Aug 2005 21:08:47 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010CCF15@cherry.ease.lsoft.com>; Mon, 15 Aug 2005 21:08:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82679537 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Aug 2005 21:08:44 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 15 Aug 2005 21:08:44 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2005 18:08:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7G18c0J026927 for ; Mon, 15 Aug 2005 18:08:39 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 21:08:40 -0400 Received: from [10.82.241.69] ([10.82.241.69]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 21:08:40 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200508150601.j7F6162i019151@sj-core-4.cisco.com> <43010905.8070208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2005 01:08:40.0346 (UTC) FILETIME=[09D2A7A0:01C5A1FF] Message-ID: <43013C97.9050800@cisco.com> Date: Mon, 15 Aug 2005 21:08:39 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43010905.8070208@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Russ, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >First, I'll comment that I believe stub areas are still useful.... > > > >>If an application requires an area flooding scope, typically its LSA will >>have the U-bit set so that the LSA be flooded as if it was understood and >>avoiding the requirement that all routers understand the new LSA. With the >>current specification in 2740, we cannot define new LSA with area flooding >>scope for Stub / NSSA unless the U-bit is clear therefore this cause two >>issues >> >>- We cannot have incremental deployment for a given application >>- We would be defining two LS type for the same application as U-bit will be >>set for regular areas and U-bit will be clear for Stub/ NSSA where all >>routers have to understand the new LSA >> >> > >Correct. > > I agree completely here. >I do see some merit in suggesting that an implemenation MAY filter >unknowns at a stub area ABR, as long as the network implementor is >willing to accept the possible negative consequences from this action. > > For stub areas, the ABR still won't allow any AS scoped LSAs to enter the area. The LSAs in question are always understood and originated by at least one router in the stub or NSSA area. Thanks, Acee >:-) > >Russ > >- -- >riw@cisco.com CCIE <>< Grace Alone > > > >-----BEGIN PGP SIGNATURE----- >Version: PGP Desktop 9.0.2 (Build 2424) > >iQA/AwUBQwEJDBEdu7FIVPTkEQK5YQCffvjVDjTfbSjZq/NAxSpqgMG7RfQAoLOK >c+Q2GrKYlQwY2zd1P3sfdDqD >=hjsk >-----END PGP SIGNATURE----- > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 16 00:33:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4t8r-0006Kf-B7 for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 00:33:37 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05171 for ; Tue, 16 Aug 2005 00:33:34 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010CD368@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 0:33:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82690444 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 00:33:15 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 00:33:15 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: OSPF WG Minutes Thread-Index: AcWhpoh7BmLR6MNUSRm4gKBsujpcYgAdK//w Message-ID: Date: Mon, 15 Aug 2005 21:34:42 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: OSPF WG Minutes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, > Acee: In practice, for OSPFv2 the sequence numbers are not monotically > increasing; Usage of router's clock for cryptographic sequence number=20 > generation reduces the chance for replay attacks across restarts.=20 > ?: OSPF spec does not say it ... Acee, what I meant was that although the OSPF spec does not state that we need to use clocks.=20 I think the vulnerabilities draft is the right place to state the problems that can happen if we do not use a clock (or something equivalent which increments even when a system goes down). Another issue is that even if the sender uses clock for the "sequence number" and goes down, all the packets of a previous session can still be replayed by another router. So the chance of replay attacks is still there. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Monday, August 15, 2005 7:50 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: OSPF WG Minutes Attached are the minutes from the Paris OSPF WG meeting. Thanks to Dimitri for taking them. Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 16 00:49:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4tO3-0000Lx-Bj for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 00:49:19 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06255 for ; Tue, 16 Aug 2005 00:49:16 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010CD3C5@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 0:49:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82690851 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 00:49:16 -0400 Received: from 203.196.196.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 00:49:15 -0400 Received: from netd.com ([10.91.0.5]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id j7G4oXuw019265; Tue, 16 Aug 2005 10:20:35 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <43016ECA.2070204@netd.com> Date: Tue, 16 Aug 2005 10:12:50 +0530 Reply-To: Mailing List Sender: Mailing List From: Ajay Thakur Subject: NSSA summarization To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi all, I have some more queries in OSPF - NSSA area. Suppose I am summarizing type-7 LSAs. In this case while generating type-5 lsa we follow section 4.1 of rfc 1587, e.g. 1> If none of the LSA's LS-Id matches to my summary-address range but LS-Id falls under configured summary address range, then we generate type-5 as per rfc 1587 -section 4.1 (2) and 2> If my LSA has LS-Id equal to summary address range then we generate type-5 lsa as per rfc 1587 section-4.1(1) Now my question is , What happens if ospf database has one LSA with LS-Id matches to my summary-address range and some LSAs with LS-Id falling under summary-address range. Then in this case what type of metric or path-type we should set in the type-5 lsa? Need your help, Thanks, with regards ajay Vishwas Manral wrote: >Hi Acee, > > > >>Acee: In practice, for OSPFv2 the sequence numbers are not monotically >>increasing; Usage of router's clock for cryptographic sequence number >>generation reduces the chance for replay attacks across restarts. >>?: OSPF spec does not say it ... >> >> >Acee, what I meant was that although the OSPF spec does not state that >we need to use clocks. > >I think the vulnerabilities draft is the right place to state the >problems that can happen if we do not use a clock (or something >equivalent which increments even when a system goes down). > >Another issue is that even if the sender uses clock for the "sequence >number" and goes down, all the packets of a previous session can still >be replayed by another router. So the chance of replay attacks is still >there. > >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Monday, August 15, 2005 7:50 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: OSPF WG Minutes > >Attached are the minutes from the Paris OSPF WG meeting. Thanks to >Dimitri for taking them. > >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 16 01:15:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4tnd-000439-Ds for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 01:15:45 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07273 for ; Tue, 16 Aug 2005 01:15:44 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010CD491@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 1:15:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82691687 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 01:15:42 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 01:15:41 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILA00822UXBRO@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 13:22:23 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILA006VAUXAY0@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 13:22:23 +0800 (CST) Received: from dell60 ([10.18.4.207]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILA00F0UV2DA5@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 13:25:26 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <002c01c5a221$95c0fb00$cf04120a@china.huawei.com> Date: Tue, 16 Aug 2005 10:45:57 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: NSSA summarization To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43016ECA.2070204@netd.com> Precedence: list Content-Transfer-Encoding: 7BIT As there is now a single type-5 lsa to represent both the exact match as well as all the LS-id's falling under the summary-address range, in my opinion the metric/path-type etc. should follow section 4.1(2). Regds, ~Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Ajay Thakur Sent: Tuesday, August 16, 2005 10:13 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: NSSA summarization Hi all, I have some more queries in OSPF - NSSA area. Suppose I am summarizing type-7 LSAs. In this case while generating type-5 lsa we follow section 4.1 of rfc 1587, e.g. 1> If none of the LSA's LS-Id matches to my summary-address range but LS-Id falls under configured summary address range, then we generate type-5 as per rfc 1587 -section 4.1 (2) and 2> If my LSA has LS-Id equal to summary address range then we generate type-5 lsa as per rfc 1587 section-4.1(1) Now my question is , What happens if ospf database has one LSA with LS-Id matches to my summary-address range and some LSAs with LS-Id falling under summary-address range. Then in this case what type of metric or path-type we should set in the type-5 lsa? Need your help, Thanks, with regards ajay Vishwas Manral wrote: >Hi Acee, > > > >>Acee: In practice, for OSPFv2 the sequence numbers are not monotically >>increasing; Usage of router's clock for cryptographic sequence number >>generation reduces the chance for replay attacks across restarts. >>?: OSPF spec does not say it ... >> >> >Acee, what I meant was that although the OSPF spec does not state that >we need to use clocks. > >I think the vulnerabilities draft is the right place to state the >problems that can happen if we do not use a clock (or something >equivalent which increments even when a system goes down). > >Another issue is that even if the sender uses clock for the "sequence >number" and goes down, all the packets of a previous session can still >be replayed by another router. So the chance of replay attacks is still >there. > >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Monday, August 15, 2005 7:50 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: OSPF WG Minutes > >Attached are the minutes from the Paris OSPF WG meeting. Thanks to >Dimitri for taking them. > >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 16 07:46:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ztR-0006bq-Cm for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 07:46:09 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04492 for ; Tue, 16 Aug 2005 07:46:07 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010CE624@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 7:46:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82751994 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 07:46:03 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 07:46:03 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Aug 2005 04:46:03 -0700 X-IronPort-AV: i="3.96,111,1122879600"; d="scan'208"; a="654959767:sNHT36926468" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7GBjvQM006744 for ; Tue, 16 Aug 2005 04:45:58 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 07:46:00 -0400 Received: from [10.82.241.69] ([10.82.241.69]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 07:46:00 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2005 11:46:00.0134 (UTC) FILETIME=[12833E60:01C5A258] Message-ID: <4301D1F7.2090000@cisco.com> Date: Tue, 16 Aug 2005 07:45:59 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF WG Minutes To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas Manral wrote: Hi Vishwas, >Hi Acee, > > > >>Acee: In practice, for OSPFv2 the sequence numbers are not monotically >>increasing; Usage of router's clock for cryptographic sequence number >>generation reduces the chance for replay attacks across restarts. >>?: OSPF spec does not say it ... >> >> >Acee, what I meant was that although the OSPF spec does not state that >we need to use clocks. > > Ok - got the update. >I think the vulnerabilities draft is the right place to state the >problems that can happen if we do not use a clock (or something >equivalent which increments even when a system goes down). > > Ok. I was just state that in practice it is not as easy to exploit as it appears. >Another issue is that even if the sender uses clock for the "sequence >number" and goes down, all the packets of a previous session can still >be replayed by another router. So the chance of replay attacks is still >there. > > You don't mean all the packets do you? You mean all the packets with the last sequence number. So, if the last packet was a hello, the session could be kept up indefinitely. Thanks, Acee >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Monday, August 15, 2005 7:50 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: OSPF WG Minutes > >Attached are the minutes from the Paris OSPF WG meeting. Thanks to >Dimitri for taking them. > >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 16 07:50:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zxm-0006x3-2J for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 07:50:38 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04688 for ; Tue, 16 Aug 2005 07:50:36 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010CE53A@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 7:50:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82752165 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 07:50:33 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 07:50:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: OSPF WG Minutes Thread-Index: AcWiWBZsFb6gojuHQqqUcEYZ+sATbgAAFBug Message-ID: Date: Tue, 16 Aug 2005 04:51:59 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: OSPF WG Minutes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, > You don't mean all the packets do you? You mean all the packets with > the last sequence number. So, if the last packet was a hello, the=20 > session could be kept up indefinitely. I think there are two parts to it. The first as you are stating it. Another is when a router has gone down, all the packets from the beginning could be replayed and the adjacency could be brought up (the receiver cannot anyway does not check for sequence number before and after an adjacency has broken). Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Tuesday, August 16, 2005 5:16 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF WG Minutes Vishwas Manral wrote: Hi Vishwas, >Hi Acee, > > =20 > >>Acee: In practice, for OSPFv2 the sequence numbers are not monotically >>increasing; Usage of router's clock for cryptographic sequence number=20 >>generation reduces the chance for replay attacks across restarts.=20 >>?: OSPF spec does not say it ... >> =20 >> >Acee, what I meant was that although the OSPF spec does not state that >we need to use clocks.=20 > =20 > Ok - got the update. >I think the vulnerabilities draft is the right place to state the >problems that can happen if we do not use a clock (or something >equivalent which increments even when a system goes down). > =20 > Ok. I was just state that in practice it is not as easy to exploit as it appears. >Another issue is that even if the sender uses clock for the "sequence >number" and goes down, all the packets of a previous session can still >be replayed by another router. So the chance of replay attacks is still >there. > =20 > You don't mean all the packets do you? You mean all the packets with the last sequence number. So, if the last packet was a hello, the session could be kept up indefinitely. Thanks, Acee >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Monday, August 15, 2005 7:50 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: OSPF WG Minutes > >Attached are the minutes from the Paris OSPF WG meeting. Thanks to >Dimitri for taking them. > >Acee > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 16 08:11:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50IN-00026x-B1 for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 08:11:55 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06059 for ; Tue, 16 Aug 2005 08:11:53 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010CE570@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 8:11:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82752764 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 08:11:52 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 08:01:52 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILB001WJDQV1G@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 20:08:55 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILB00DK6DQVFN@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 20:08:55 +0800 (CST) Received: from Ashokc1721 ([10.18.4.127]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILB00H9IDVX08@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 20:11:58 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c5a25a$633aee50$7f04120a@china.huawei.com> Date: Tue, 16 Aug 2005 17:32:33 +0530 Reply-To: Mailing List Sender: Mailing List From: ashok Subject: Re: OSPF WG Minutes To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7BIT Hi Vishwas, -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Tuesday, August 16, 2005 5:22 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF WG Minutes Hi Acee, > You don't mean all the packets do you? You mean all the packets with > the last sequence number. So, if the last packet was a hello, the > session could be kept up indefinitely. I think there are two parts to it. The first as you are stating it. Another is when a router has gone down, all the packets from the beginning could be replayed and the adjacency could be brought up (the receiver cannot anyway does not check for sequence number before and after an adjacency has broken). For this to happen, ALL ospf packets sent by the router which is now down, has to be stored by the malicious router and it has to be replayed in the same sequence. However, the LSAs will eventually maxage as the malicious router cannot possibly refresh the lsas. So the condition is bounded by OSPF max-age. But, this still does pose a seemingly improbable problem. Thanks, Ashok Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Tuesday, August 16, 2005 5:16 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF WG Minutes Vishwas Manral wrote: Hi Vishwas, >Hi Acee, > > > >>Acee: In practice, for OSPFv2 the sequence numbers are not monotically >>increasing; Usage of router's clock for cryptographic sequence number >>generation reduces the chance for replay attacks across restarts. >>?: OSPF spec does not say it ... >> >> >Acee, what I meant was that although the OSPF spec does not state that >we need to use clocks. > > Ok - got the update. >I think the vulnerabilities draft is the right place to state the >problems that can happen if we do not use a clock (or something >equivalent which increments even when a system goes down). > > Ok. I was just state that in practice it is not as easy to exploit as it appears. >Another issue is that even if the sender uses clock for the "sequence >number" and goes down, all the packets of a previous session can still >be replayed by another router. So the chance of replay attacks is still >there. > > You don't mean all the packets do you? You mean all the packets with the last sequence number. So, if the last packet was a hello, the session could be kept up indefinitely. Thanks, Acee >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Monday, August 15, 2005 7:50 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: OSPF WG Minutes > >Attached are the minutes from the Paris OSPF WG meeting. Thanks to >Dimitri for taking them. > >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 16 11:15:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53AN-0008U0-8x for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:15:51 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17400 for ; Tue, 16 Aug 2005 11:15:48 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010CE78E@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 11:15:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82771424 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 11:15:43 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 11:15:34 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01LRW0W0P46O004OJN@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 08:18:55 -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: <01LRW0W0P46Q004OJN@omega7.wr.usgs.gov> Date: Tue, 16 Aug 2005 08:18:55 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: NSSA summarization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list >Suppose I am summarizing type-7 LSAs. In this case while generating >type-5 lsa we follow section 4.1 of rfc 1587, ... >What happens if ospf database has one LSA with LS-Id matches to my >summary-address range and some LSAs with LS-Id falling under >summary-address range. Then in this case what type of metric or >path-type we should set in the type-5 lsa? What Sujay suggests is clearly described in RFC 3101 Section 3.2, namely: (3) Else the Type-7 LSA must be aggregated by the most specific Type-7 address range that subsumes it. If this Type-7 address range has the same [address,mask] pair as the LSA's network and no other translatable Type-7 LSA with a different network best matches this range, then flag the LSA as not contained in any explicitly configured Type-7 address range and process the LSA as described in step (2). Otherwise compute the path type and metric for this Type-7 address range as described below... RFC 3101 obsoletes RFC 1587. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 16 14:37:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56Jo-00045K-CK for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 14:37:50 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27743 for ; Tue, 16 Aug 2005 14:37:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010CE9A1@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 14:37:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82785341 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 14:37:34 -0400 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 14:37:34 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7GIbSZ5031838 for ; Tue, 16 Aug 2005 19:37:31 +0100 X-X-Sender: paul@sheen.jakma.org References: <4301D1F7.2090000@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-ID: Date: Tue, 16 Aug 2005 19:37:28 +0100 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: OSPF WG Minutes To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4301D1F7.2090000@cisco.com> Precedence: list On Tue, 16 Aug 2005, Acee Lindem wrote: > You don't mean all the packets do you? You mean all the packets > with the last sequence number. Nah, /all/ packets. 'Kick' the victim router hard enough so it stays down. Then wait for the dead-interval and the victim's peers will/should forget the sequence number. Then you can replay everything. Though, not sure how you'd get past database exchange, as the router-being-spoofed need not use same state (DD sequences, LSA seqnum's), etc. Seems theoretical to me too. ;) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Nadia Comaneci, simple perfection. -- '76 Olympics From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 17 06:49:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5LU2-0002fN-94 for ospf-archive@megatron.ietf.org; Wed, 17 Aug 2005 06:49:22 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20712 for ; Wed, 17 Aug 2005 06:49:19 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010CF759@cherry.ease.lsoft.com>; Wed, 17 Aug 2005 6:49:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82866592 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Aug 2005 06:49:17 -0400 Received: from 64.233.170.200 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 17 Aug 2005 06:39:17 -0400 Received: by rproxy.gmail.com with SMTP id i8so110395rne for ; Wed, 17 Aug 2005 03:39:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mD/gCQOviCLG1Wi53PAa95vL11Y4Kxqvz2RlTmKUPJFmdImvpfqyBwpT/P4OUhf8DWNxoR+RVT2lWfL/BE+/DmbA8CINI4xYNFo1cLNu5B/t+2Og4hytgN/mOBkjqg6ouDlvH9NUdI0v2nTPBuRe4cTGWTZGfMO5BL8xXiy01jI= Received: by 10.11.88.41 with SMTP id l41mr7166cwb; Wed, 17 Aug 2005 03:39:16 -0700 (PDT) Received: by 10.11.116.18 with HTTP; Wed, 17 Aug 2005 03:39:16 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: Date: Wed, 17 Aug 2005 06:39:16 -0400 Reply-To: Mailing List Sender: Mailing List From: Srinivas Akkipeddi Subject: OSPF Multi-Area Adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Acee, In the last IETF it was said that OSPF Multi-Area Adjacency (draft-ietf-ospf-multi-area-adj-03.txt) is not on the standards track because of lack of implementation. But there are implementations of this draft in progress. Srinivas Akkipeddi Avici Systems From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 17 10:11:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5OdX-0000Xn-Kr for ospf-archive@megatron.ietf.org; Wed, 17 Aug 2005 10:11:23 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02676 for ; Wed, 17 Aug 2005 10:11:21 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010CF927@cherry.ease.lsoft.com>; Wed, 17 Aug 2005 10:11:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82880680 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Aug 2005 10:10:55 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 17 Aug 2005 10:10:55 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 17 Aug 2005 10:10:55 -0400 X-IronPort-AV: i="3.96,116,1122868800"; d="scan'208"; a="66808409:sNHT32008172" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7HEANTW011876 for ; Wed, 17 Aug 2005 10:10:53 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 10:10:51 -0400 Received: from [10.82.241.69] ([10.82.241.69]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 10:10:50 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2005 14:10:50.0644 (UTC) FILETIME=[78DF9540:01C5A335] Message-ID: <43034569.3020601@cisco.com> Date: Wed, 17 Aug 2005 10:10:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF Multi-Area Adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Srinivas Akkipeddi wrote: >Acee, > >In the last IETF it was said that OSPF Multi-Area Adjacency >(draft-ietf-ospf-multi-area-adj-03.txt) is not on the standards track >because of lack of implementation. But there are implementations of >this draft in progress. > > Ok - I don't have any problems with this. I'm sure the ADs won't mind waiting a bit to review. >Srinivas Akkipeddi >Avici Systems > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 18 19:00:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tMs-0007xt-BC for ospf-archive@megatron.ietf.org; Thu, 18 Aug 2005 19:00:14 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11429 for ; Thu, 18 Aug 2005 19:00:11 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010D1091@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 19:00:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83054565 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 19:00:08 -0400 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 18:50:08 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5tCz-0000wl-Fr; Thu, 18 Aug 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Thu, 18 Aug 2005 18:50:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-graceful-restart-02.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPFv3 Graceful Restart Author(s) : P. Pillay-Esnault, A. Lindem Filename : draft-ietf-ospf-ospfv3-graceful-restart-02.txt Pages : 11 Date : 2005-8-18 This memo describes the OSPFv3 graceful restart. For OSPFv3, graceful restart is identical to OSPFv2 except for the differences described in this memo. These differences include the format of the grace Link State advertisements (LSA) and other considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-graceful-restart-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-18154330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-graceful-restart-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-18154330.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 19 13:47:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Axa-0007fo-U9 for ospf-archive@megatron.ietf.org; Fri, 19 Aug 2005 13:47:18 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19022 for ; Fri, 19 Aug 2005 13:47:16 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010D1E76@cherry.ease.lsoft.com>; Fri, 19 Aug 2005 13:47:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83157282 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 19 Aug 2005 13:47:10 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 19 Aug 2005 13:47:10 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Aug 2005 10:47:10 -0700 X-IronPort-AV: i="3.96,126,1122879600"; d="txt'?scan'208"; a="206278014:sNHT37224804" Received: from smirtorawxp (dhcp-128-107-177-71.cisco.com [128.107.177.71]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7JHl72i027104 for ; Fri, 19 Aug 2005 10:47:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01F5_01C5A4AB.5797DBA0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWkLnsPz3cWm3nBRseISZlO24DaNAAqxGDA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: <200508191747.j7JHl72i027104@sj-core-4.cisco.com> Date: Fri, 19 Aug 2005 10:47:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: I-D ACTION:draft-mirtorabi-ospf-tag-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_01F5_01C5A4AB.5797DBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, This draft was presented in the last IETF meeting in Paris, here is the link to the new version of the draft, comments are welcome. Thanks Sina -----Original Message----- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to OSPFv2 for Advertising Optional Route/Link Attributes Author(s) : S. Mirtorabia, et al. Filename : draft-mirtorabi-ospf-tag-01.txt Pages : 20 Date : 2005-8-18 There are applications which require additional attributes to be advertised with an OSPF link or route. The existing OSPF LSA formats do not allow for backward compatible extension to advertise these attributes. This draft proposes an extension to OSPF for advertising additional attributes which will be associated with a link or route. It also introduces the support of administrative tags for any link type in the router-LSA and any route in summary-LSAs, NSSA-LSAs, or AS-external-LSAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tag-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mirtorabi-ospf-tag-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mirtorabi-ospf-tag-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j7IJqJVf023916 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc ------=_NextPart_000_01F5_01C5A4AB.5797DBA0 Content-Type: text/plain; name="ATT00223.txt" Content-Disposition: attachment; filename="ATT00223.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_01F5_01C5A4AB.5797DBA0-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 24 13:38:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zCS-0003wH-S6 for ospf-archive@megatron.ietf.org; Wed, 24 Aug 2005 13:38:08 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07301 for ; Wed, 24 Aug 2005 13:37:54 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010D6D79@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 13:37:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83754864 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 13:37:46 -0400 Received: from 216.148.213.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 13:27:44 -0400 X-Mail-Filter: Tumbleweed MailGate 2.5.1-4097 Received: by mailgate1.tumbleweed.com (Tumbleweed MailGate, from userid 124) id 7D59733C01A; Wed, 24 Aug 2005 10:16:42 -0700 (PDT) X-TMWD-Spam-Summary: SEV=1.1; DFV=A2005081808; IFV=2.0.4,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34333035304633352E303031373A534346454F31313438302D462D586C496B3278353041585648704F677067516E4E68773D3D; ENG=IBF; TS=20050818224633; CAT=NONE; CON=NONEX-MMS-Spam-Filter-ID: A2005081808 X-Filter-Reason: Magic; 119; 0ILFWLL-28CA-00G; 5D49F8F04FEB0D073832BB91B738F730 X-Mail-Filter: Tumbleweed MailGate 2.5.1-4088 Received: from mgedge1.tumbleweed.com (mgedge1.tumbleweed.com [10.48.5.13]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mailgate1.tumbleweed.com (Tumbleweed MailGate) with ESMTP id 7A3D033C004 for ; Thu, 18 Aug 2005 15:46:33 -0700 (PDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgedge1.tumbleweed.com (Tumbleweed MailGate Edge) with ESMTP id 0AE53F0003 for ; Thu, 18 Aug 2005 15:54:50 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tDG-00051U-Qv; Thu, 18 Aug 2005 18:50:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tD6-0004yf-FI for i-d-announce@megatron.ietf.org; Thu, 18 Aug 2005 18:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09480 for ; Thu, 18 Aug 2005 18:50:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5tmw-0001Dh-77 for i-d-announce@ietf.org; Thu, 18 Aug 2005 19:27:10 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5tCz-0000wl-Fr; Thu, 18 Aug 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: i-d-announce.ietf.org Errors-To: i-d-announce-bounces@ietf.org Message-ID: Date: Thu, 18 Aug 2005 18:50:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-graceful-restart-02.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPFv3 Graceful Restart Author(s) : P. Pillay-Esnault, A. Lindem Filename : draft-ietf-ospf-ospfv3-graceful-restart-02.txt Pages : 11 Date : 2005-8-18 This memo describes the OSPFv3 graceful restart. For OSPFv3, graceful restart is identical to OSPFv2 except for the differences described in this memo. These differences include the format of the grace Link State advertisements (LSA) and other considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-graceful-restart-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-18154330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-graceful-restart-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-18154330.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 26 15:03:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jUC-0002O0-3Z for ospf-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:03:32 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06876 for ; Fri, 26 Aug 2005 15:03:30 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010D93D1@cherry.ease.lsoft.com>; Fri, 26 Aug 2005 15:03:26 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84016260 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 26 Aug 2005 15:03:25 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 26 Aug 2005 15:03:25 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8jU4-000ICI-0K; Fri, 26 Aug 2005 19:03:24 +0000 X-Priority: 3 (Normal) References: <43034569.3020601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1823895478.20050826120311@psg.com> Date: Fri, 26 Aug 2005 12:03:11 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPF Multi-Area Adjacency Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43034569.3020601@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Absolutely. It's definitely a good idea to wait until/if people implement it. -- Alex http://www.psg.com/~zinin Wednesday, August 17, 2005, 7:10:49 AM, Acee Lindem wrote: > Srinivas Akkipeddi wrote: >>Acee, >> >>In the last IETF it was said that OSPF Multi-Area Adjacency >>(draft-ietf-ospf-multi-area-adj-03.txt) is not on the standards track >>because of lack of implementation. But there are implementations of >>this draft in progress. >> >> > Ok - I don't have any problems with this. I'm sure the ADs won't mind > waiting a bit to > review. >>Srinivas Akkipeddi >>Avici Systems >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 26 16:00:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kMz-0003bQ-Qb for ospf-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:00:11 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13344 for ; Fri, 26 Aug 2005 16:00:05 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010D9472@cherry.ease.lsoft.com>; Fri, 26 Aug 2005 16:00:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84018633 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 26 Aug 2005 16:00:03 -0400 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 26 Aug 2005 15:50:03 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E8kDC-0001sC-D1; Fri, 26 Aug 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Fri, 26 Aug 2005 15:50:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-06.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF for IPv6 Author(s) : D. Ferguson, et al. Filename : draft-ietf-ospf-ospfv3-update-06.txt Pages : 97 Date : 2005-8-26 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload. Even with larger IPv6 packet, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-update-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-26120840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-update-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-26120840.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 30 09:16:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5yA-0003GN-FN for ospf-archive@megatron.ietf.org; Tue, 30 Aug 2005 09:16:06 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11674 for ; Tue, 30 Aug 2005 09:16:04 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010DC86C@cherry.ease.lsoft.com>; Tue, 30 Aug 2005 9:16:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84344152 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Aug 2005 09:16:01 -0400 Received: from 202.54.64.23 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 30 Aug 2005 09:16:00 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Aug 2005 18:45:54 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Aug 2005 18:45:54 +0530 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 Aug 2005 13:15:54.0213 (UTC) FILETIME=[F36AE150:01C5AD64] Message-ID: <15226CC274ADF842929EEAB80EB965F0FD347C@kavithai.ctd.hcltech.com> Date: Tue, 30 Aug 2005 18:45:49 +0530 Reply-To: Mailing List Sender: Mailing List From: "Srinivasaragavan Jayaraman - CTD, Chennai" Subject: Reg: DR/BDR election To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi All, I have a doubt regarding the DR/BDR election process. In section 9.4 of RFC 2328, it says that the router having the highest priority might not necessarily be the DR and nor the one having = the second highest priority be the BDR. We are aware that this situation = could arise when a higher priority router comes up after the DR and BDR are elected. Can the above situation occur in any other instance? Some one plz clarify. Thanks Regards Srinivasaragavan J DISCLAIMER=20 This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies=20 and its customers. Contents may be privileged or otherwise protected by = law. The information is solely intended for the=20 individual or the entity it is addressed to. If you are not the intended = recipient of this message, you are not authorized to=20 read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error,=20 please notify the sender immediately by return e-mail and delete it from = your computer From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 31 11:50:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUqe-0003I6-IN for ospf-archive@megatron.ietf.org; Wed, 31 Aug 2005 11:50:00 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27720 for ; Wed, 31 Aug 2005 11:49:57 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010DDFD5@cherry.ease.lsoft.com>; Wed, 31 Aug 2005 11:49:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84483334 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 31 Aug 2005 11:49:55 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 31 Aug 2005 11:49:55 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2005 11:49:56 -0400 X-IronPort-AV: i="3.96,158,1122868800"; d="scan'208"; a="68504619:sNHT31361788" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7VFnqT6021283; Wed, 31 Aug 2005 11:49:53 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:49:39 -0400 Received: from [64.102.194.234] ([64.102.194.234]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:49:39 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2005 15:49:39.0597 (UTC) FILETIME=[989683D0:01C5AE43] Message-ID: <4315D193.50205@cisco.com> Date: Wed, 31 Aug 2005 11:49:39 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: draft-ietf-l3vpn-ospf-2547-04 L3VPN/OSPF WG Last Call Comments: cc: l3vpn@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit This begins working group last call on draft-ietf-l3vpn-ospf-2547-04. This last call is limited to the changes that Eric has made to the document (which are outlined in Eric's email below). The last call will end in two weeks (September 14th). Please send any comments to the l3vpn (l3vpn@ietf.org) and OSPF WG mailing lists. The document is an l3vpn WG document but it reflects OSPF operation/interaction with BGP/MPLS in a PE/CE environment. Thanks, Acee At 11:45 AM 8/29/2005 -0400, Eric Rosen wrote: > As a result of AD review, significant changes have been made > to the > specification draft-ietf-l3vpn-ospf-2547. These changes can be seen > in the > latest version, draft -04. It is believed that the draft now > corresponds to > the implementations. > > The following issues were addressed as a result of the AD review. > > The spec was written so as to allow a single VRF to correspond to > multiple > OSPF domains. However, it did not make clear just which > parameters and > procedures are relative to a domain, and which are relative to a > VRF. This > has now been cleared up. However, doing so required extensive > textual > changes. > > There are cases where BGP decides to put a route into the VRF > for a > particular address prefix, and OSPF also decides to put a route into > the VRF > for that same address prefix. Of course, only one of these can > actually be > used for forwarding. The original spec did not make it adequately > clear > just how a choice between two such routes would be made. This > has been > clarified. In some cases, the results will be different than they > would > have been if the VPN were really a pure OSPF network. These > differences are > now explained and their potential consequences pointed out. > > The procedures for forwarding data traffic on a sham link > have been > clarified. The procedures for sending OSPF control traffic on a > sham link > have been clarified. The role of the optional "sham link endpoint > address" > has been clarified. > > The procedures for translating BGP-distributed VPN-IPv4 routes > into OSPF > routes have been clarified. > > A discussion of NSSA routes has been added. Alex says it is not > detailed > enough; any feedback in this area would be welcome. > > Due to the large number of changes, Alex has asked for a new last > call, and > I expect the WG chairs to formally issue the last call shortly.