Re: Type-7 to Type-5 translation issue

Acee Lindem <acee@CISCO.COM> Mon, 16 May 2005 10:24 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 GAA20666 for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 May 2005 06:24: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 <17.010496D0@cherry.ease.lsoft.com>; Mon, 16 May 2005 6:24:40 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 70887407 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 06:24:39 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 16 May 2005 06:24:39 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 16 May 2005 06:24:39 -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 j4GAOanI010743 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 16 May 2005 06:24: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); Mon, 16 May 2005 06:24:36 -0400
Received: from [10.82.225.188] ([10.82.225.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 06:24:36 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <c4bf85a2050514081066c7ef0a@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2005 10:24:36.0141 (UTC) FILETIME=[756C0DD0:01C55A01]
Message-ID: <428874E3.1020408@cisco.com>
Date: Mon, 16 May 2005 06:24:35 -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: Type-7 to Type-5 translation issue
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <c4bf85a2050514081066c7ef0a@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Santosh,

Whether or not R1 purges its AS-external-LSAs prior to area 1 being
coverted from a regular area to an NSSA is implementation specific. 
However, the
timing of the conversion may be such that R1 is unable to purge them 
from the
OSPF routing domain. In all cases, R1 should immediately originate 
NSSA-LSAs
(type-7s) for redistributed routes. When R2 computes its external/NSSA 
routes
it should not use R1's AS-external-LSA since its path to the ASBR is not 
through
a regular area (see section 2.5 in RFC 3101).

Hope this helps,
Acee

Santosh Esale wrote:

>Hi guys,
>           Mine topology is as below-
>
>R1----Area 1 ------R2--------Backbone Area------R3
>
>Initially Area 1 was type-5 capabale area and i was redistributing RIP
>routes into area 1 on R1, so R2 and R3 have type-5 LSAs for all the
>RIP routes.Now i changed
>Area 1 to NSSA , So R1 is now orginating type-7 LSAs for all the RIP
>routes into area 1 with P-bit set.
>
>Now mine question is should R2 -
>
> 1.     Prefer type 7 LSA over type-5 .
>Convert type-7 LSA into type-5 LSA  and flood into backbone, which
>aleardy have  type-5 LSAs for the same netwroks earlier orginated by
>R1(not yet flushed as it will remain in backbone for MAX AGE)
>(According to RFC 3101. section 2.5 stp 6 (e) ).
>
>Disadvantage: The LSP database size will be doubled till MAX AGE time.
>Advantage : simplicity
>
>2. Prefer type-5 over type-7 .
>Use type-5 LSA for calculating external routes till type-5 LSAs
>advertised by R1 exists in backbone(MAX Age) , and once type is
>flushed because of MAX age , USE type -7 now to calculate external
>routes , and translate at this point from type-7 to type-5(RFC 1587
>3.5 step 5)
>
>Advantage : LSP database size is small.
>Disadvantage: bit complex,but not much.
>
>3. or its Implementations Specific.
>
>Thanks in Advance
>
>
>  
>