Re: Indication LSA impact

Acee Lindem <acee@CISCO.COM> Tue, 10 May 2005 12:15 UTC

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 IAA19995 for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 May 2005 08:15:39 -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.0103E4DF@cherry.ease.lsoft.com>; Tue, 10 May 2005 8:11:24 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 70088627 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 May 2005 08:11:22 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 10 May 2005 08:11:19 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 10 May 2005 08:11:20 -0400
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 j4ACB0nU011028 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 10 May 2005 08:11:17 -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); Tue, 10 May 2005 08:11:09 -0400
Received: from [10.82.216.165] ([10.82.216.165]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 08:11:08 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <062B922B6EC55149B5A267ECE78E5D4406A5C8A9@photon.jnpr.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 May 2005 12:11:08.0863 (UTC) FILETIME=[594D84F0:01C55559]
Message-ID: <4280A4DC.2090001@cisco.com>
Date: Tue, 10 May 2005 08:11: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: Re: Indication LSA impact
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <062B922B6EC55149B5A267ECE78E5D4406A5C8A9@photon.jnpr.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Kaylan,

Kalyan Bade wrote:

>Folks,
>
>I was going through rfc 1793 (demand circuit extensions for OSPF) and
>have a question regarding the generation of indication LSAs and its
>impact on the LSAs created/flooded.
>
>Suppose if we have three routers as shown in the setup below.
>
>R0 ------ R1 ------ R2
>   Area X    Area Y 
>
>Say if R0 is a DC uncapable router, the area X is considered DC
>uncapable. Which means that none of the routers in area X can generate
>an area scope/AS scope LSAs with DoNotAge bit set. 
>
>And as per the spec, an indication LSA is generated in area Y and this
>makes the area Y also as DC uncapable. So, my question is what is the
>rationale behind making area Y as DC uncapable? I understand that any
>router in area Y shouldn't generate an AS scope LSA with DoNotAge bit
>set, but why should that hold to area scope LSA's?
>  
>

I don't recall all the discussions surrounding this draft. However, I 
suspect it was a design
choice to simplify the backward compatibility mechanism. On the surface, 
I see no
reason why what you are suggesting could not have been done with some 
additional
protocol specification and state.

Thanks,
Acee

>Thanks,
>Kalyan. 
>
>  
>