RFC 2370 Update and a Proposed Change to Stub Area Behavior

Acee Lindem <acee@CISCO.COM> Tue, 03 May 2005 14:43 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25322 for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 May 2005 10:43:59 -0400 (EDT)
Received: from vms.dc.lsoft.com ( by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010317C4@cherry.ease.lsoft.com>; Tue, 3 May 2005 10:43:59 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69121290 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 May 2005 10:43:58 -0400
Received: from by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 3 May 2005 10:43:21 -0400
Received: from rtp-core-2.cisco.com ( by rtp-iport-2.cisco.com with ESMTP; 03 May 2005 10:43:21 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com []) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j43Eh3e1013134 for <ospf@peach.ease.lsoft.com>; Tue, 3 May 2005 10:43:18 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 10:43:09 -0400
Received: from [] ([]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 10:43:08 -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: 03 May 2005 14:43:08.0977 (UTC) FILETIME=[6C6C3A10:01C54FEE]
Message-ID: <42778DFC.4060107@cisco.com>
Date: Tue, 03 May 2005 10:43:08 -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: RFC 2370 Update and a Proposed Change to Stub Area Behavior
Precedence: list
Content-Transfer-Encoding: 7bit

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 
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.