Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior

Acee Lindem <acee@CISCO.COM> Thu, 11 August 2005 21:03 UTC

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 <ospf-archive@LISTS.IETF.ORG>; 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 <OSPF@PEACH.EASE.LSOFT.COM>; 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 <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
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 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
>